Secure authentication and payment system

ABSTRACT

The present invention provides a service for allowing secure financial transactions to be carried out, the service involving authenticating a user&#39;s identity and/or status as part of a financial transaction with another party and in the event that the user is authenticated arranging for the transaction to be completed without revealing the user&#39;s financial details and/or other personal details to that other party. Authentication data and transaction data may be communicated over any suitable communications channel(s). The invention provides a trusted authentication and payment environment that protects a user&#39;s financial details, but allows them to be securely authenticated and arranges for transactions to be fulfilled, whilst providing other parties with reassurance that transactions will be completed. In this way, fraud and theft due to misappropriation of financial details can be minimized.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No.14/716,519, filed May 19, 2015, which is a continuation of U.S.application Ser. No. 13/838,764, filed on Mar. 15, 2013, which is acontinuation of U.S. application Ser. No. 11/692,656, filed Mar. 28,2007, which is based on, and claims priority to GB Application No.0621189.0, filed Oct. 25, 2006, the entire contents of each of which areincorporated fully herein by reference.

FIELD OF THE INVENTION

The present invention relates to a system, method and apparatus foridentity authentication and/or secure payment.

BACKGROUND OF THE INVENTION

Technology has revolutionized the way that consumers make purchases andexpanded the range of retail channels. Goods may be purchased in a rangeof ways including traditional face-to-face purchases, mail order andtelephone order as well as more recent retail formats such as Internetshopping, purchase by mobile phone and other contactless purchasemethods. The number of payment options has also expanded to suit andinclude credit cards, debit cards, charge cards, contactless walletpayment systems such as Oyster, Speedpass and vending cards, directdebit from bank accounts and payment using mobile phone accounts. Thisproliferation of payment and retail systems, whose transactions areoften conducted remotely or between consumers and merchants who havelittle or no prior relationship, has led to a change in the securitychallenges faced by consumers, merchants and financial institutions.

Using existing payment card systems in transactions such as mail order,Internet shopping and purchases over the telephone, a consumer givestheir complete payment and identity details up front and has to trustthat the goods and services will be delivered and that the merchant islegitimate and uses the details given only for processing that order.This exposes the consumer to identity theft, theft of payment detailsand payment fraud via, for example, phishing, swiping cards throughnon-authorized card readers and simple misuse or copying of carddetails. These theft and fraud threats are not presently secured byexisting payment security methods such as those typically employed bycredit card processors. Similarly, merchants must trust that theconsumer has given the correct identity, is an authorized user of thepayment method and that the payment details are correct. In addition,merchants are exposed to identity fraud or deception where payment oraccount details have been stolen.

To meet these challenges, credit card companies and financialinstitutions are putting security measures into place. The introductionof chip and PIN (EMV authentication) in the UK for card transactions hasreduced fraud in the face-to-face market. Whilst this is undoubtedly asignificant improvement in security, face-to-face fraud does stilloccur, exemplified by some major merchants withdrawing their chip andPIN payment terminals after their compromise. Indeed, a directconsequence of chip and PIN at point of sale is that consumers are nowopen to greater risk of shoulder surfing. Further threats to securitymay arise from the use of electronic “bugging” equipment in point ofsale terminals.

Card detail theft is also an issue, with fraudsters using legitimatecard details to perpetrate non-face-to-face and face-to-face paymenttheft. This is because existing terminals and PIN pads are designed toaccept many cards from consumers without requiring specific validationby the merchant or staff members before use. In addition, terminals thatare not validated by the registered merchant can give rise to high fraudlevels if compromised. This is due to the lack of accountability overtheir security, and the nature, size and technical needs of existingterminals and PIN pads, making it difficult to keep them secure when notbeing used. Furthermore, card details taken from the face and back ofpayment cards can be fraudulently used across non-chip and PIN channels.

SUMMARY OF THE INVENTION

According to the present invention, there is provided a service forallowing secure financial transactions to be carried out, the serviceinvolving authenticating a user's identity and/or status as part of afinancial transaction with another party and in the event that the useris authenticated arranging for the transaction to be completed withoutrevealing the user's financial details and/or other personal details tothat other party.

Authentication data and transaction data may be communicated over anysuitable communications channel, and in some circumstances arepreferably communicated over different communications channels.

The invention provides a trusted authentication and payment environmentthat protects a user's financial details, but allows them to be securelyauthenticated and arranges for transactions to be fulfilled, whilstproviding other parties with reassurance that transactions will becompleted. In this way, fraud and theft due to misappropriation offinancial details can be minimized.

Authenticating the user may involve receiving authentication data inputby the user via a communications channel. Multiple communicationschannels may be available. For example, user data may be received via awireless telecommunications network and/or the Internet and/or e-mailand/or any other suitable communications channel. Preferably, the methodinvolves allowing the user to select a preferred communications channel.Different communications channels may be selected for differenttransaction types. For example, the user may prefer to communicateauthentication data via a mobile telephone network, when transacting viathe Internet.

Communications to the user may be sent via any suitable communicationschannel, for example a wireless telecommunications network and/or theInternet and/or e-mail. Preferably, communications to the user are sentvia a different channel to those from the user. For example, messagesmay be sent to the user via e-mail but received from the user via amobile telephone network. Events of which the user may be notifiedinclude authentication failures and/or mismatch of order detailssupplied by differing users and/or the order is available for dispatchand/or the order is only partially fulfilled and/or a payment is refusedand/or a transaction has been referred and/or the consumer has, or isclose to, breach of their operating parameters. A confirmation may besent and payment may be withheld until the confirmation is received. Theuser being notified may have to provide identification informationbefore access is given to the notification.

The authentication may be two-stage, but preferably is three-stage. Eachauthentication stage may involve input of personal identificationnumbers and/or code words and/or personal details and/or answers tochallenge questions and/or matching of a user with a list of authorizedusers for a transaction device and/or cross referencing two or more setsof input authentication data. Authentication may involve comparing theinput data with user related data stored by the system. Authenticationmay involve online and/or offline authentication stages.

The service may allow a user to register one or more payment means. Theuser may assign a particular payment means for use in specifiedtransactions. For example, the user may specify that a credit card is tobe used for Internet transactions, but a debit card is to be used withperson to person transactions. Additionally or alternatively, the usermay specify that a particular card or account may be used fortransactions only with a particular organization, such as a merchant orretailer. Payment may be made when the paying user'sauthentication/identification code is provided rather than details ofthe payment means to be used.

One of the user's payment means may be used in the step ofauthenticating the user. The payment means used for authentication ispreferably different from the payment means used to complete thetransaction. This provides an added level of security for the user.

The service may further include storing authentication data associatedwith at least one user and authentication is by comparing data suppliedby the user with stored authentication data. The authentication may beassociated with a transaction. The transaction may be a purchase or acash withdrawal or money transfer.

The service may further include defining operating parameters for a userand checking that transactions do not breach those operating parametersbefore making payment.

The service may further involve allocating a user identification code toa first user, providing the first user's identification code to a seconduser and comparing the first user's identification code with data storedin user records to confirm that the first user is a registered user ofthe system.

Payment may be held in escrow until goods have been dispatched. Thisprovides an added level of security for users, especially when thetransaction is via Internet or mail order.

According to another aspect of the invention, there is provided atransaction system that is configured to authenticate a user and arrangea financial transaction with another party based on the user'sauthentication and without disclosing the user's financial detailsand/or personal identity to that other party.

Preferably, the transaction is payment for goods and/or services.Preferably, the system includes authentication means for authenticatingthe user and payment means that are functionally and/or physicallyseparate from authentication means, the payment means being adapted toarrange for payments.

By separating authentication from the transaction, users can beauthenticated and transactions authorized without providing the user'sfinancial details to other users. This provides protection againstmisuse of, for example a user's debit or credit card, should it becomecompromised. In this way, fraud and theft due to misappropriation offinancial details can be minimized.

All users that are party to a transaction may be authenticated in thesame way, regardless of whether they are retailers or consumers. Thisminimizes fraud on both sides of a transaction.

The system may be adapted to receive order details from at least twousers, for example a consumer and a merchant, and to compare the orderdetails received from each user to ensure that both sets of orders areidentical. The system may be adapted to arrange payment only if theorder details match. In this way the system can minimize errors in theorder process and also fraudulent altering of transactions.

The system may be adapted to arrange payment directly from a useraccount, for example a credit or debit card account or any otherfinancial vehicle provided to allow the user to make payments.Alternatively, before forwarding arranging for payment from a useraccount, the system may be adapted to receive payment and hold it inescrow until goods are dispatched or services provided and/or the useracknowledges the payment is valid.

The payment may be a cash withdrawal or cash advance. The system may beadapted to be used with transactions over one or multiple transactionchannels. This may be achieved by provision of a communications systemfor allowing users to interact with the system via for example theInternet (and other networks using an IP protocol), telephone or mobiledata communications services.

The transaction channels may include face-to-face, mail order, telephoneorder, Internet shopping, user-to-user transfers, purchase by mobilephone and other contactless purchase methods. In this way, the systemprovides a unitary authentication and payment management system that canbe used in many retail formats, allowing the user to use one account andauthentication method to centrally control many payment means andauthenticate and arrange payment in many transaction channels.

The system may be adapted to apply the same authentication regardless oftransaction channel, so that a consistent level of security is appliedin all transactions. Alternatively, differing authentication may beapplied to differing transaction channels. This allows the degree ofauthentication to be tailored to suit factors related to the transactionchannel such as the inherent security of the transaction channel.

The system may be adapted to store authentication data associated withat least one user on the system. The system may authenticate the user'sidentity and/or status by comparing data supplied by the user withstored authentication data. The system may be adapted to carry outauthentication associated with a transaction.

The system may be adapted to receive data from a transaction device, thetransaction device having means for inputting data and means forcommunicating data to the system. The means for inputting data may be akeypad and/or a trackball and/or a joystick and/or a biometric featurereader and/or a reader. The biometric feature reader may include afingerprint reader and/or a retinal scanner and/or a voice analyzer. Thecard reader may be a chip card reader and/or a magnetic strip cardreader and/or a radio frequency identification (RFID) card reader.

The means for communicating data may include any wireless or mobiletelecommunications apparatus and/or bluetooth communications apparatusand/or WiFi communications apparatus, such as WiFi 802.11 a/b/gcommunications apparatus and/or infrared communications apparatus and/orRFID communications apparatus and/or NFC communications apparatus and/ora USB port and/or a firewire port. The mobile telecommunicationsapparatus may be adapted to operate over GPRS or 3G or GSM or CDMAnetworks.

The means for communicating data may be adapted to allow the transactiondevice to communicate with payment systems, for example RFID or NFCbased payment systems, to allow the transaction device to operate inplace of the payment means, e.g. a RFID card such as an Oyster card,associated with the payment system.

Authentication may involve at least two-stages, and preferably three.Each authentication stage may require input of personal identificationnumbers and/or code words and/or personal details and/or answers tochallenge questions and/or biometric data and/or matching of a user witha list of authorized users for a transaction device and/or valid readingof an EMV compliant card or other registered identity card and/or crossreferencing two or more sets of provided authentication data.Authentication may involve comparing the input data with user relateddata stored by the system. Authentication may involve online and/oroffline authentication stages.

The system may be adapted to store user names and/or user identificationcodes and/or user addresses and/or user address codes and/or userpayment account details and/or user operating parameters and/or usertransaction histories and/or audit trails.

The system may be adapted to process orders using a user identificationcode and a delivery address code uniquely associated with a user. Thesystem may be adapted to receive the delivery address code of a firstuser, determine the address corresponding to the delivery address codeand to provide the address to at least a second user only when the atleast second user confirms that it is in a position to fulfill thetransaction. By only revealing a user's address once all the users havebeen authenticated and only at a stage in the transaction when theinformation is necessary, the disclosure of user information isminimized, helping to prevent identity fraud.

The system may be adapted to have more than one payment means associatedwith each user. Each payment means may be assigned for use in specifiedtransactions. The system may be adapted to use a payment means to carryout a payment after authenticating both users and when provided with thepaying user's identification code rather than details of the paymentmeans (e.g. PayPal, credit card, etc.) to be used. This again minimizesthe information disclosed by a user during a transaction and helpsprevent identity fraud and misuse of payment details.

The system may be adapted to send a notification to users to confirmevents. The notification may be a short message service (SMS) message,e-mail, telephone call or message sent to a transaction device.Preferably, the notification is via a different notification method tothe placing of the order. In this way, if a communications means iscompromised and used to place a fraudulent transaction, then the userwill receive notification of the transaction by a differentcommunications channel, allowing them to detect and stop the fraudulenttransaction.

Events of which the user may be notified may include authenticationfailures and/or mismatch of order details supplied by differing usersand/or the order is available for dispatch and/or the order is onlypartially fulfilled and/or a payment is to be made and/or a payment isrefused and/or a transaction has been referred and/or the consumer has,or is close to, breach of their operating parameters.

The system may be adapted to require a confirmation to the notificationbefore processing a payment. The system may be adapted to obtainidentification information from the user before providing access to thenotification so as to prevent erroneous notification of someone otherthan the user.

The system may be adapted to assign at least one user identity code toat least a first user, whereby the authentication means are adapted tovalidate the identity and/or status of the first user to a second userupon provision of the first user's identity code to the system by thesecond user.

The user data used for validation may be whether or not a user is aregistered user of the system and/or the user is transacting withinspecified criteria and/or the user account has permission for carryingout that transaction. The specified criteria may include thattransactions values and/or transaction velocities are within a set limitor that the transaction is of a specified type. This allows the users tohave increased confidence in transacting with other users.

Each user may be associated with at least one sub user. The system maybe adapted to register users or sub-users and to only allow access tothe system by registered users or sub-users. For example, pre-registeredand designated staff (sub-users) may transact on behalf of a retailer(user). This allows for individual traceability and accountability.Authentication of a user may include authentication of at least oneassociated sub-user.

The system may require re-authentication by at least one user if atransaction has not been completed within a specified time-scale. Thesystem may require at least one user to review and/or accept atransaction if the transaction has not been completed within a specifiedtime-scale.

The system may be adapted to allow each user to make or receive paymentsin a currency of choice. The system may be adapted to convert thecurrency of a payment such that the currency in which a payment is madeis different to the currency in which the payment is received.

According to yet another aspect of the invention, there is provided atransaction device for collecting and communicating authentication datahaving data input means and communications means for use with the methodand system of the other aspects.

According to a fourth aspect of the present invention, there is provideda computer program, or a storage means containing a computer program ora server programmed with a computer program for implementing any of theother aspects of the invention.

According to yet another aspect of the invention, there is provided amethod involving using an authentication means associated with aconsumer to authenticate a merchant. Preferably, the authenticationmeans is an authentication device, for example a mobile wirelessauthentication device. Preferably the consumer device comprises a cardreader and/or a keypad and/or biometric feature reader and/or an RFIDdetector. Preferably the method further involves arranging payment fromthe consumer to the authenticated merchant using the consumer'sauthentication means.

BRIEF DESCRIPTION OF THE DRAWINGS

Various aspects of the invention will now be described by way of exampleonly and with reference to the accompanying drawings of which:

FIG. 1 is an overview of the interaction between an authentication andpayment system, users of the system, payment account issuers andmerchant and payment acquiring banks and processors;

FIG. 2 is a schematic representation of how the authentication andpayment system interacts with a user and the user's accounts;

FIG. 3 is a schematic of the authentication and payment system of FIG.1;

FIG. 4 is a further schematic of the components of the authenticationand payment system of FIG. 1 and its interaction with users;

FIG. 5 shows how users can interact with the system of FIG. 1;

FIG. 6a is a front view of an authentication device for use with thetransaction system 1 of FIG. 1;

FIG. 6b is an internal view of an authentication device for use with thetransaction system 1 of FIG. 1;

FIG. 6c is first side view of an authentication device for use with thetransaction system 1 of FIG. 1;

FIG. 6d is another side view of an authentication device for use withthe transaction system 1 of FIG. 1;

FIG. 6e is yet another side view of an authentication device for usewith the transaction system 1 of FIG. 1;

FIG. 7 is a flow diagram of an authentication and payment method;

FIG. 8 is a flow diagram of a user registration method;

FIG. 9 is a flow diagram of a user maintenance method;

FIG. 10 is a flow diagram of a notification method;

FIG. 11 is a flow diagram of a user service review method;

FIG. 12 is a flow diagram of a method for authenticating a user;

FIG. 13 is a flow diagram of a method for triple authenticating amerchant;

FIG. 14 is a flow diagram of a method for validating a merchant'sidentity;

FIG. 15 is a flow diagram of a method for validating a consumer'sidentity;

FIG. 16 is a flow diagram of a method for validating a consumer'spayment ability;

FIG. 17 is a flow diagram of a method for validating that goods areready for dispatch;

FIG. 18 is a flow diagram of a method for consumer acceptance/rejectionof a payment;

FIG. 19 is a flow diagram of a method for fulfilling an order;

FIG. 20 is a flow diagram of a method for processing referred consumertransactions;

FIG. 21 is a flow diagram of a consumer rejection process;

FIG. 22 is a flow diagram of a method for processing chargebacks, and

FIG. 23 is a flow diagram of a method for processing credits.

DETAILED DESCRIPTION

FIG. 1 shows a secure transaction system 1 that is run by a systemoperator for identity authentication and authorizing payment. Thetransaction system 1 is able to communicate with users that aretransacting with one another, for example a consumer and a merchant. Itis also able to communicate with the systems of institutions 2 a-c, 4that provide users with financial services, for example banks, creditcard companies etc. The transaction system 1 acts as a gateway forauthenticating the identities of users who are parties to transactionsand for arranging for payments to be made without disclosure of a user'sfinancial details. To do this, the system 1 implements securityprocedures at various stages in a transaction and controls and arrangespayment from one user to another user only when one and preferably bothusers have been fully authenticated and without the paying user'sfinancial details, for example credit or debit card details, beingrevealed to the other user.

The transaction system or system operator 1 is not a bank or paymentprovider but sits between these providers and the user, and acts as asecure, trusted system for arranging payment from one user to anotheronce a transaction has been fulfilled and only once the identities ofboth users have been authenticated and appropriate security checks havebeen completed. The system 1 is not designed to replace a merchant'sordering system and transactions are still conducted between a consumerand the merchant over conventional commercial channels, such as face-toface interaction 6, mail order 8, telephone order 10, Internet shopping12, contactless 14, mobile 16 and person-to-person 18 payment. Instead,the system 1 allows a user to transact with merchants over numerousdifferent channels, using a single authentication means 20 to interactwith the system 1, thereby to be authenticated and arrange for payment,without having to reveal financial details to the merchant. The system 1provides multi-channel, consistent anti-fraud measures and validationservices to users to ensure that the other users involved in thetransaction are who they claim and are transacting within allowedlimits. Transactions can be recorded with the system 1, but only toallow checks that the transaction is as expected and to release userinformation or arrange payment at appropriate stages in the transaction.

By having the authentication and security aspects of a transactionhandled separately from the users, banks or other facilities that canarrange payment and ordering systems, the system 1 can be implemented tooperate consistently with a wide range of payment means and use a rangeof transaction channels 6-18. Use of the system brings the same level ofsecurity and protection across multiple commercial channels 6-18. Inaddition, authentication is carried out on a transaction level, not on apayment level. These aspects allow the user to interact with a single,unitary authentication and security system 1 thereby to authorizepayment from any of their nominated accounts, rather than having to dealwith a multitude of specific authentication and payment systems tied tocertain payment facilities, for example banks or credit card providers,merchants or transaction channels.

As shown in FIG. 2, the single user authentication means 20 can be usedfor authentication, whilst providing access to at least some andoptionally all payment channels nominated by that user, for example acontactless tag account 22, a first credit card account 24 a, a secondcredit card account 24 b, a mobile telephone account 26, a loyaltyscheme 28, a first bank account 30 a,a second bank account 30 b, and agift voucher scheme 32. The authentication means could be for example adedicated consumer ID card 34/merchant card 36 and/or consumerauthentication device 38/merchant authentication device 40 or could be acredit or debit card that the user has nominated for use in theauthentication process. Since the authentication and payment processesare decoupled, even where a credit or debit card is used forauthentication, this does not necessarily have to be used for payment.Indeed by using one card for authentication and another for payment,security can be increased. For example in the arrangement of FIG. 2, acredit card could be used for authentication, but the user could arrangefor payment via any one or more of the contactless tag account 22, thefirst and second credit card accounts 24 a,b, the mobile telephoneaccount 26, the loyalty scheme 28, etc.

FIG. 3 shows the transaction system 1 in more detail. This includes atransaction server 42 for applying security procedures to transactions;an authentication server 44 for authenticating user identities; apayment server 46 for liaising with the consumer's payment means 47 andarranging actions, such as payments or bank transfers, on behalf ofusers; storage media 48 for storing data relating to users, transactionsand operating parameters; and a communications system 50 forcommunicating with users, other parties such as issuing institutions,and operators of the system. The transaction server 42, authenticationserver 44, payment server 46 and any server required by thecommunications system 50 may be physically separate. Alternatively, oneor more of the transaction system server functions 42-50 may beincorporated within the same physical server.

The transaction system 1 acts as a gateway so that users can controlwhat information is provided to other users and at which point in thetransaction that information is provided. As all users are part of atrust network, they can have confidence that certain information is heldon the system 1 and can be used, or appropriately accessed, to completethe transaction. This negates the need for a user to supply thatinformation, which prevents it being used fraudulently by another user.This gateway function is facilitated by the transaction server 42, whichis adapted to carry out security operations at various stages of thetransaction. The security operations may include storing details of auser and arranging actions using the user's details rather thanrevealing the details to the other users, for example by arrangingpayments from one user to another without revealing details of thepayment channel 47. The security operation may only reveal certaindetails of the user at an appropriate stage in a transaction, forexample, for non-face-to-face transaction where goods are not providedat the point of sale, by revealing address details only when goods areready for dispatch.

Further security operations carried out by the transaction server 42include allowing users to record expected transactions with thetransaction system 1, the transaction server 42 being adapted to comparethe transactions to ensure that they match. The transaction server isfurther adapted to record in the memory 48, at least in an aggregated orgeneralized manner, each user's transaction history and monitor usertransactions against a series of operating parameters to allow furthercontrol of the user's account and to limit exposure to fraud. Thetransaction server 42 is also adapted to notify the user at variousstages in a transaction using the communications system 50 such thatusers are aware of details of the transaction and can detect and stopfraudulent transactions.

The transaction system 1 is adapted to register users of the system onlyon completion of a series of registration checks. To ensure that a userwishing to take part in a transaction is the registered user, theauthentication server 44 authenticates their identity using at leasttwo-stage (double) and typically three-stage (triple) authentication aswill be described in more detail later. In this way, other users of thesystem 1 can have confidence that they are transacting with anothermember of a trusted network, upon whom certain checks have been made andwhose identity has been authenticated. The authentication server is alsoadapted to allow users to check that other users are registered with thesystem 1 by submitting a user identification code, amongst otherdetails, to the authentication server 44 which is adapted to compare thesupplied consumer identification code and details with those storedwithin user records to provide an indication that the user is aregistered user.

The memory/storage media 48 includes a fast access, high capacitystorage system, such as a hard disk bank, although any suitable storagemeans may be used. User records, for example consumer records 54 andmerchant records 56, are stored in the storage medium 48. These includeuser data such as name, identity code, delivery and billing addressesand associated address codes, details of payment means such as creditcard 24 a,b, debit card 30 a,b or bank account 30 a,b details,authentication data such as passwords, PIN codes and challenge questionssuch as the user's mother's maiden name, school, place of birth, etc,data required to comply with regulating authority regulations, servicesettings such as preferred payment methods and operating parameters,such as maximum transaction volume, value and type settings, transactiondata, audit trails and user/transaction status such as “active”, “onhold”, etc.

The authentication server 44 is able to access the storage media 48 forrecording and accessing user records 54, 56, transaction histories andaudit trails and the communications system 50 for communicating withusers, authentication devices 38, 40 and service operators.Authentication requests and data are received from users via thecommunications system 50. The authentication server 44 is adapted toprocess the requests and data via a triple authentication method forrequests received from an authentication device 38, 40, or by a doubleauthentication method for requests received without use of anauthentication device 38, 40, and return an identity validity indicationto the payment server 46, transaction server 42 or requesting user viathe communications system 50.

The payment server 46 is operable to process payment requests andcommunicates these to the user's payment means issuer 2 a-c. The paymentserver 46 is arranged to process payment requests only when certaincriteria have been met, such as authentication of both users by theauthentication server 44, the transaction leading to the payment requestdoes not breach operating parameters of either user or that thetransaction expected by each user matches the transaction expected byother users that are party to that transaction. As the payment server 46handles any payment request and arranges payment, when a consumer and amerchant are transacting, the consumer's financial details are notavailable to the merchant.

The payment server 46 is able to access the storage means 20 to retrieveuser details, such as the user's payment means 22-32, required to carryout the action. The payment server 46 also has access via thecommunications system 50 to the servers of other parties involved, e.g.issuers of payment means 2 a-c, such as a credit card company or bank.The payment means 22-32 may be a credit card account 24 a,b, a debitcard account 30 a,b, a bank account such as a current account, acontactless account 22 such as an Oyster card, a customer loyalty schemeaccount 28, a gift card scheme 32 or a mobile phone service account 26.The payment means 22-32 is operated, and any payment made, by a paymentissuer 2 a-c such as a bank or credit card company separate from thetransaction system 1. The payment server 46 is adapted to act as anintermediary to process payment requests and arrange payment uponcompletion of orders, obtain validations of consumer payment means 22-32from issuers 2 a-c upon request from a merchant, or other authenticateduser (for example for user-to-user transactions such as via PayPal orWestern Union transfers), and arrange chargebacks and credits.

FIG. 4 shows the communications system 50, which links the transactionsystem 1 with various parties involved in the placing and processing oftransactions such as consumers, merchants and financialinstitutions/payment issuers 2 a-c, 4. Various servers and associatedhardware are provided, such as an Extranet/Internet server 86 and mobilecommunications server 88. Also provided are appropriate firewall routersfor fixed line communication 90, mobile data communication 92 andInternet communication 94. The communications system 50 is adapted toprovide communications by a range of methods such as Internetcommunications, e-mail, GPRS, SMS, RFID, telephone, Interactive VoiceResponse (IVR) as will be described in greater detail later. Thecommunications system 50 also provides link to terminals 96 for allowingsystem operator staff to access the transaction system 1, for example inresponse to telephone enquiries. Users can communicate with thetransaction system 1 by one communications method, and the system 1 cannotify the user of transactions by another communications method. Thesecommunications methods can be pre-defined by the user. For example, theuser may opt to send instructions and/or information to the system 1 viamobile telephone, but receive information via the Internet. This helpsprevent fraudulent or unauthorized intervention through unauthorizedaccess to a single communications medium. In addition, it allows thetransaction system 1 to be used with a variety of transaction types andnegates the necessity for every user to have expensive processingterminals.

FIG. 5 shows the transaction types supported by the system 1. Theseinclude mail order 8, face-to-face 6, Internet ordering 12, telephoneordering 10, Internet 102 and telephone banking and transactions 16using mobile communications technology such as various technologiesemploying WAP, i-mode, 3G and GPRS. As shown in FIG. 4, merchants'servers 104 can access the transaction system 1 directly via fixed linecommunications or over the Internet or Extranet. Authentication devices38, 40 belonging to consumers or merchants access the system via mobilecommunications capability directly contained within the authenticationdevice 38, 40 or indirectly via connection to a user's terminal 106 orvia an adapter or modem 108 to another communications system such as atelephone line 110. Users may also access the system via voicetelecommunications 110 to an operator 96 or to an IVR service. Accessvia a user mobile telephone 110 may additionally include use ofmessaging services such as short messaging service (SMS) messages oraccess via a mobile browser such as WAP or via a direct network linksuch as those available over 3G networks. These communications areintercepted and decoded by the mobile communications server 88. Users,whether merchants or consumers, may access the system from terminals 106such as PC's over the Internet, which are via an interactive Extranet orInternet service and controlled by the Internet server 86.

FIGS. 6a-e show an authentication device 38, 40 for allowing input ofuser authentication data, communications of data to and from thetransaction system 1 and display of instructions from the transactionsystem 1 to the user. The authentication device 38, 40 has a display112; data input devices as appropriate such as a keypad 114, trackball116, microphone 118, touch pad (not shown), and/or buttons 120; abiometric information reader 122 such as fingerprint scanner or aretinal scanner; a card reader 124 such as a chip card reader,preferably Europay MasterCard Visa (EMV) compliant, and/or magneticstrip card reader and/or an RFID card reader; cable and/or wirelesscommunications means such as a Bluetooth port 126, an IR port 128, RFIDport 130, USB port 132, Firewire port , 802.11a/b/g wireless (“Wi-Fi”)communications apparatus 136 and/or mobile telecommunications apparatus138 including a SIM card and SIM card reader; and a rechargeable battery140; along with the associated hardware required to run each of thesecomponents, as would be understood by a person skilled in the art. Theauthentication device 38, 40 further contains memory 142 and processingmeans 144 for storing data, processing operations and controlling thecomponents. The authentication device may comprise separate logicaland/or physical memory configurations for payment and other functions.

The authentication device 38, 40 is associated with certain users andlocked for use by those users. The users authorized to use theauthentication device 38, 40 and associated identification data requiredto unlock the device 38, 40, such as PIN code or consumer ID code arestored in the memory 142 of the authentication device 38, 40, which isupdated from the transaction system 1 via the communications system 50.The device 38, 40 will only become operable to communicateauthentication data to the transaction system 1 once a user hasvalidated their identity, for example by using an identity card and/orPIN and/or ID code. Data can be input to the device 38, 40 in responseto prompts displayed on the display 112. Activation of individual inputdevices 114-124 or operation of the display 112 may be in response tosoftware stored on the authentication device 38, 40 or in response toinstructions received from the transaction system 1 via at least one ofthe communications means 126-138.

The communications means 126-138 of the authentication device 38, 40 areadapted to link the authentication device 38, 40 with the transactionsystem 1 and may be used to send update data, user data or instructionsto the authentication device 38, 40 or to relay authentication data tothe transaction system 1. The preferred communications route is viaencrypted mobile communications over networks such as GPRS or 3G. In anoptional embodiment, the card reader 124 may be adapted to receivecontactless payment cards, including RFID cards such as Oyster,Speedpass or vending system cards. The RFID port 130 of theauthentication device can then be used to communicate between theauthentication device 38, 40 and a contactless card system to makepayments. This allows for use of contactless payment cards or accountsto be made dependant on completion of the authentication procedures. Thecontactless card may be used to make payments over other paymentchannels 24-32 via the transaction system 1. In this, case thecontactless card could be preloaded with funds and used as a user'spayment account for transactions via the transaction system 1.Conversely, other payment accounts, e.g. credit 24 or debit cards 30,could be used to make contactless payments.

FIG. 7 shows the steps for authenticating users using the transactionsystem 1 to facilitate a secure transaction, including authenticatingthe identities of users who are parties to a transaction and controllingdelivery and payment. All parties to a transaction must be registeredusers of the transaction system 1 before being allowed access to thesystem 1. A potential user must first complete a registration procedure146 to obtain details necessary for operation of the transaction system1 and to ensure that all the details are correct and that all regulatoryrequirements are met. The users can be specified as being consumers, whoonly use the transaction system 1 to make purchases from a merchant, ormerchants, who use the transaction system 1 to make sales to a consumeror another merchant acting as a consumer. A merchant may also makepurchases and any reference to a consumer includes merchants when makinga purchase. For transactions such as person-to-person or Western Uniontype transfers, both users may be consumers, with one user acting as a‘merchant’ in so much as they receive a payment. As an optional feature,the transaction system 1 may act as a directory or database of merchantsoffering services or products through which consumers may browse tolocate a suitable supplier with whom they can transact in a safe andsecure fashion. At the end of the registration procedure, each consumeris given a consumer identity code and each merchant is given a merchantidentity code.

Once registered, a consumer wishing to make a transaction with amerchant must first access the transaction system 1 and authenticate 148their identity to prove that they are who they claim to be and that theyare registered on the transaction system 1. After the consumer has beenauthenticated 148, they request validation 150 of the identity of themerchant with whom they wish to transact by sending to the transactionserver a merchant identity code. This would be supplied to them by themerchant by normal commercial means, e.g. via a website or advert. Theauthentication server 44 is then operable to compare the suppliedmerchant identity code with those stored on the transaction system 1. Apositive match allows the consumer to have confidence that the merchanthas passed the transaction system registration checks and is operatingwithin its operational parameters. The consumer then transmits anexpected order 152 to the transaction system 1. The transaction system 1stores the expected order for comparison with the order placed on thetransaction system 1 by the merchant to ensure that the details of theactual order matches the expected order details. This procedure isconsumer driven and so is ideal for mail order 8, transactions over theInternet 12, and telephone shopping 10.

The merchant accesses the transaction system 1 and goes throughauthentication 154. This ensures that they are an authorized user andthe intended party to the transaction. The merchant may seek to validate156 the identity of the consumer by supplying the consumer's identitycode to the transaction system 1. The authentication server 44 of thetransaction system 1 is operable to compare the user identification codewith those stored by the transaction system 1. This can be used to checkthat the identity provided by the consumer is correct and that theconsumer has passed the registration conditions of the system 1 and isoperating within their operational parameters. The merchant may alsoaccess the transaction system 1 to validate 158 that the consumer'sselected payment means 22-32 are valid for use and not showing as stolenor suspended. The transaction system 1 can process these requests bychecking for appropriate status flags stored in the consumer's recordand by using the payment server 46 to communicate with the issuinginstitutions 2 a-c of the consumer's payment means to carry out fundsavailable and other standard security checks, as would be known in theart.

The transaction system 1 notifies the consumer of the transactiondetails recorded on the system by the merchant and gives the consumer anoption to reject the transaction or flag up any fraudulent transactions160. The transaction system 1 also makes referral checks 162 to ensurethat the consumer's payment means 22-32 is valid and within the limitsset by the consumer's issuer 2 a-c and that both consumer and also themerchant are within their operating parameters. Only once the goods orservices are ready for dispatch 164 to the consumer is any consumerpersonal address information 54 released to the merchant by thetransaction system 1. After dispatch 164 of the goods or services, thetransaction system 1 processes 166 the payment for the goods or servicesfrom the consumer's payment issuer 2 a-c to the merchant through themerchant's acquiring bank 4. The details of the consumer's payment means22-32 is never revealed to the merchant, thus ensuring a separation ofauthentication and payment. The transaction system 1 also providesfacilities for control of post sales transactions such as chargebacks168 and credits 170 utilizing its advantageous authenticationfacilities.

FIG. 8 shows the registration process 146 in detail. This requirespotential users to provide their identities (including name, address andcertain payment and banking information) and verify those identitiesusing reliable, independent source documents, data or information. Wherethe potential user is a business or corporate body, the beneficial ownermust be identified and steps taken to verify the identity of thebeneficial owner. Details are also required on the purpose and intendednature of the business relationship with the potential user. These maybe used to determine the risks associated with each user and to conductongoing due diligence on the business relationship and scrutiny oftransactions undertaken throughout the course of that relationship toensure that the transactions being conducted are consistent with theactivities of the user, their business and risk profile, including,where necessary, the source of funds. To this end, the transactionsystem 1 may distinguish between merchants and consumers at all times tohelp determine the expected activities and incorporate these into riskanalysis by determining whether actual usage matches this expectedprofile.

The preferred method of ensuring the details supplied in the uservalidation are correct is to obtain a reference 172 from a bank or othersponsoring institution. A potential user may request registration bycompleting an application form (which may be electronic, such as anInternet form). If the potential user has an existing relationship andis referred by a bank or other institution (retail or otherwise) thatrequires to follow the same regulatory requirements as the transactionsystem 1 operator, the prospective user may provide details of the bankas a referee to confirm that the prospective user has undergone therequired regulatory checks by that bank or institution. The prospectiveuser must also provide appropriate permission for the transaction system1 operator to contact the prospective user's clearing bank and to givethe bank or institution authorization to release the informationrequired. The bank or sponsoring institution is then contacted 174 toconfirm that the prospective user has undergone a consumer validationprocess that meets regulatory requirements and to confirm that thedetails supplied by the prospective user are correct. This approach maybe enhanced by credit reference agency checks as appropriate.

Where the reference is positive, full application details for theprospective user are assessed 176 to determine whether a serviceagreement should be granted. Assessment 176 is preferably carried outusing underwriting analyses/scorecards as is known in the art. If thereference or subsequent risk analysis is negative, account-openingprocedures are not initiated 178 and the outcome is referred back to theprospective user and the sponsoring institution as appropriate. A recordof this event is also sent to audit trail logs. If the potential userdoes not elect to provide a bank reference, then optionally other checks180 may be employed that depend on local regulatory requirements andsystem operator policy as would be known in the art. If the other checksare unsuccessful, the audit logs are updated and the account is notopened 182. Where the checks (either via a bank reference or otherprocedure) are successful 184, the prospective user is notified of thesuccessful application, and a user record is set up 186 as either aconsumer record 54 or a merchant record 56. Users are issued with aservice agreement setting out their conditions of operating and agreeinginitial operating parameters for their account.

Once accepted, the new user provides user and preference details. Thiscan be achieved by: (a) secure access to the system via an Extranet; (b)communication with the service centre staff; (c) via an IVR system; or(d) via written documentation provided through registered postal means.The user and preference details to be provided will vary depending onwhether the user is a consumer or a merchant. If the user is a consumer,the details required 188 are: (a) name, address, employment and identitydetails; (b) details of further consumers who may use the account (e.g.in the case of a household or group account); (c) the method ofcommunication based on specific notifications; and (d) multi-currencytransaction base currency. In addition, the consumer has to indicatepreferred consumer communication methods, for example, telephone, mobilephone, text message, email address; specific criteria for eachcommunication method preferred, based upon predefined criteria, i.e.which communication formats to use to communicate which events (e.g.account or transaction queries); details of the payment means 22-32 tobe used, including card and non-card payment means; unique consumerpreferences and operating parameter 60 checks for: specific identityauthentication and transaction payment combinations; for each identity /payment combination, preferences for the payment channel 22-32, withidentification of default accounts for each channel for fasterprocessing; transaction and gross values over specified periods; paymentvelocities; and merchant type exclusions or limitations. The systemimposes transaction volume, value and velocity limits based on eachconsumer's application details.

The consumer also has to indicate any preference for trustingtransactions if the transaction value in transaction or base currencymatches an order that has been pre-loaded by the consumer. Even wherethis option is selected, the consumer will still be notified of anypayment transaction using the consumer's account. The user also has toprovide the address details 54 for goods delivery and invoice dispatchto which address codes 76 will be assigned. In addition, the user has toselect alphanumeric passwords 78 for Extranet, authentication device 38and IVR use. Multiple passwords may be selected for different users ofan account. An answerback PIN for SMS messages and alphanumericanswerback password for email notifications may also be selected atregistration. Where appropriate, an initial password to facilitateauthentication device 38 registration of consumer biometric identitymeans (e.g. fingerprint) will also be registered or generatedautomatically during registration. Preference over the time delay afterwhich an order is deemed to be an “aged order” and requires to berevalidated and accepted by the consumer may be set and optionally maydepend on the payment channel.

At registration, the consumer may also select the level of service. Thisis principally a choice between an authentication device 38 and identitycard 34, which allows triple authentication, or an identity card only34, which allows dual authentication. For those selecting anauthentication device 38, its use can be limited to purchasing itemsonly or for both purchase and sale of items. This feature isadvantageous for example for PayPal power sellers or small traderstrading under a trusted network. In addition, the user may specifywhether or not they wish to transact cash withdrawals in a virtual ATMarrangement. For accounts where more than one user is authorized to usean authentication device 38, each authorized user will select his/herown password, and register his/her unique payment methods, and havehis/her own identity card 34. A maximum number of users and identitycards 34 per authentication device 38 is imposed, with payment cardsbeing uniquely linked to specific authentication devices for consumeridentity verification and security purposes.

Where an authentication device 38 is selected, the user can selectpreferred components, e.g. one or more of: GPRS/mobile communications138; Bluetooth communications 126; 802.11a/b/g Wi-Fi communications 136;USB communications 132; Firewire communications 134; Contactless (RFiD)or NFC communications 130; Wallet capability for contactless payments(where the contactless close proximity channel is selected by theprincipal consumer); PayPal or small merchant seller functionality.Person-person money transfer capability will be set automatically inaccordance with the principal consumer payment type preferences.

At registration, default fulfillment choices should be made regardingthe period over which the consumer is prepared to wait during delays ingoods dispatch from the merchant, either overall or by transactionchannel and merchant type. Mail order will be extended by a defaultnumber of days to facilitate postal order timescales but not facsimileor email orders. This will be defaulted to a preset limit based onservice arrangements with merchant users. This facilitates notificationsfrom the transaction system 1 to remind the consumer that the defaultdelay period is close to being met. Where no delay is selected, thesystem will automatically prompt the consumer to acknowledge that goodshave been received before allowing transactions to complete.

For registration of a merchant, the details required 190 are name,address, merchant classification and identity details; details of allmerchant staff who are to be issued with identity cards 36 (identitycards 36 will be capable of being reallocated to new members of staff aschanges occur); and member(s) of merchant staff to be granted authorityto change or reset the PIN on identity cards 36. Where more than onemember of staff is to use an authentication device 40, the merchant canselect the functions to which each member of staff will have access. Inthis way the merchant can ensure segregation of duties between differentparts of the payment process, for example, order input and fulfillment.A maximum number of merchant staff and therefore identity cards 36 perauthentication device 40 will be imposed. Preferred merchantcommunication methods have to be chosen, for example telephone, mobilephone, text message, email address, as do rules for each communicationmethod, based upon predefined criteria (e.g. to use a certaincommunications route for account notifications or a differentcommunications route for transaction queries or to select which eventsare to result in notifications).

Details of which payment acceptance methods are to be used, such as cardand non-card payment, also have to be defined. Unique merchantpreferences can be selected for: payment types, e.g. credit and debitcard, accepted across each payment channel, for example face-to-face 6,Internet 12, mail order 8. For each payment channel selected, themerchant can define the estimated values for the numbers oftransactions; the gross value of transactions over specified periods;the volume of transactions over specified periods; and exclusions orlimitations on specific payment types. The system 1 will imposeoperational parameters such as transaction volume, value and velocitylimits based on each merchant's application details, and will limitspecific transaction levels based upon levels of credits, complaints,referrals and other service characteristics. Where delays in dispatch ofgoods are typical in the merchant's business, the time periods that aretypical before dispatch of goods takes place can be specified. Thesedelays will be built into the service agreement with merchants, andmonitored by the system.

Other preferences that have to be defined include the method ofcommunication to the merchant in response to specified notificationtriggers; multi-currency transaction base currency and acceptance ofspecific currencies elected by consumers using the system. This may bepart of a dynamic currency conversion (DCC)/consumer preferred currency(CPC) service provided by the system, as do any preferences for trustingtransactions if the transaction value or base currency matches an orderthat has been pre-loaded by a consumer. Where this option is selected,the merchant will still be notified of payment transactions impactingthe merchant account. Alphanumeric passwords for use with Extranet,authentication devices and interactive voice response (IVR) may also bedefined, and multiple passwords may be selected for different merchantmembers of staff. In addition, an answerback PIN for SMS notifications,and an alphanumeric answerback password for email notifications, may beselected. Where appropriate, an initial password to facilitateregistration of merchant biometric identity means, e.g. fingerprint, foruse with an authentication device 40 is also be registered or generatedautomatically.

As for the consumer, the merchant can also select the level of serviceby choosing between authentication using an authentication device 40 andidentity card or identity card 36 only. A limited number of identitycards will be provided to merchants, which may or may not be linked tospecific authentication devices. For those selecting the authenticationdevice 40, the merchant may elect to use it only for selling items orfor both sale of items and providing consumers with cash withdrawalfacilities. Also, where an authentication device 40 is selected, themerchant has to indicate whether a Bluetooth enabled base station isrequired for connection to a fixed telephone line or mobiletelecommunications device for communication between the authenticationdevice 40 and the system 1. Authentication device 40 componentpreferences also have to be included for example: GPRS/mobilecommunications; Bluetooth communications; 802.11a/b/g Wi-Ficommunications; USB communications; Firewire communications, andContactless (RFiD) or NFC communications (receiver).

The transaction system 1 will determine chargeback reserves according tomethods known in the art and provide details of chargeback reserves tobe applied as part of the merchant application process.

Once the user's details and preferences are entered, the transactionsystem 1 determines operational parameters, e.g. according to value,quantity or velocity for each user and records these in the user'srecord 54, 56. Then authentication devices 38, 40 and/or identityvalidation cards 34, 26 are issued where applicable by secure delivery.At this state, an identity tag, unique to the authentication device38,40, is stored either in or in association with the user's record, sothat the device is uniquely linked with that user or a designated groupof users. Authentication devices 38, 40 and identity cards 34, 36 areonly enabled after the user provides a combination of pre-registeredpersonal details and passwords, which have all already been registered,to validate their identity. Where a user only has identity cards 34, 36,contact with the transaction system 1 must be by telephone, IVR orExtranet. Once the user account is enabled, the user is then free to usethe transaction system 1 within the terms of their service agreement.

The registration details and operational parameters may be modifiedusing account maintenance as shown in FIG. 9. Each user's record can beaccessed 200 for maintenance purposes via any of the communicationsmethods supported by the system such as using an authentication device38, 40, via telephone to an operator, IVR, Internet/Extranet, e-mail,mobile phone access, e.g. via WAP, i-mode or 3G, text message or RFIDlink. The user provides their user identity code and the systemdetermines from this whether or not the user is a consumer or a merchant202. The user then has to be authenticated 204, 206. Access to theaccount maintenance system is by triple authentication if the user isusing an authentication device 38, 40 or double authentication if notusing an authentication device as described below. Once the user hasbeen authenticated, they may modify 208 the user's details and thoseoperational parameters 35 that the system 1 allows the user to alter.

The system maintains a transaction activity logs for recording alltransactions made by a user and an audit log for recording any instanceswhere a transaction, registration or access attempt fails or isrejected, orders are rejected by a consumer along with an appropriatereason code, or payment is declined or referred. An expected userbehavioral pattern based on information gathered at registration iscreated. This behavioral pattern is used to determine operationalparameters that are agreed with the user. As each user account is used,the transaction data is recorded in the transaction log and audit trailas appropriate in addition to other data as supplied by the issuers 2a-c of payment cards or other payment means to monitor the behavior ofthe users. The user's credit and fraud risk is calculated periodicallyand/or upon transactions being made by methods known in the art toprovide a constant assessment of risk to the transaction system 1operator. As shown in FIG. 10, a notification system is provided withtrigger events set to provide user information or communication, orprovide a warning when operational parameters are breached or the systemdetermines that the credit or fraud risk is too high.

The form of notification may be specified by the user at registration orduring account maintenance. It may be any notification type known in theart, but is preferably an SMS message, a message sent to and displayedon an authentication device 38, 40, an e-mail or a telephone call froman operator. When an event triggers a notification, a message is sent tothe user 210. To ensure that the user receives the notification and nota third party, the user will be required either (a) to respond to an SMSmessage with a predefined password set at registration before thenotification is sent; or (b) will be referred to a link by email whichwill transfer the consumer to a secure Extranet facility which willrequire validation by password or authentication device 140 set atregistration 212. Once the user has been verified, the notification isaccessed 214.

Each user account is assigned notification triggers in response tooperational parameter breaches that are used to control risk and to flagup any operations that are out with the service agreed during theregistration, maintenance or review processes. Grace limits abovetransaction limits are set to create shadow limits, which act as abuffer against any minor breach of the transaction limits. Consumeraccounts are reviewed periodically and/or when a transaction is made. Ifa consumer is: (a) in breach of its transaction limits (over and aboveany shadow limit); or (b) where the system has detected an unusual orsuspicious transaction, the system will lock the user account byrecording a “hold” flag on the user's account such that the user will beunable to use the system for any purpose, including validation of theconsumer identity to third parties, until it has undertaken a servicereview, as shown in FIG. 11.

A service review involves a user contacting an operator to discuss theproblem 216. Before discussing the problem, the user supplies theiridentity code from which it can be determined if the user is a consumeror merchant 218. The user then validates their identity 220, 222 usingtriple authentication if using an authentication device 38, 40 or doubleauthentication if not using an authentication device 38, 40 as describedbelow. If the authentication is successful, a service review iscommenced 224. The operator may agree a change in the user's serviceagreement or operational parameters 35. Where satisfactory arrangementsare agreed between the operator and the consumer 226, for example anincrease in transaction limits if appropriate, the user's account isupdated accordingly and the “hold” flag is removed from the user'saccount such that the user may use the system again. Where appropriatearrangements are not reached 228 with an operator, the operator may,according to predefined criteria, keep the “hold” flag on the consumer'saccount until settlement and satisfaction of the service agreement; orpermanently disable the consumer's account. Details of the limit breachand subsequent interaction are recorded in the audit logs 230.

The authentication procedure depends on whether the user is using anauthentication device or not and whether or not the user is a consumeror a merchant. If an authentication device is used, then the user musttriple authenticate their identity. If authentication is carried outwithout an authentication device, then the user must double authenticatetheir identity. Alternately, the method for authentication without useof an authentication device can be used as a backup only when theauthentication device(s) are unavailable or incapacitated. Regardless ofthe authentication method used, personal details of the consumer, suchas payment details, are not communicated to the merchant, therebysignificantly reducing the possibility of identity theft, theft ofpayment details and/or payment fraud. Only after both parties areauthenticated as being recognized and trusted users can paymentprocessing proceed.

As shown in FIG. 12, the first step is to identify whether the user is aconsumer 232, and if yes, whether an authentication device is to be used234. If the user is a consumer and authentication is to be carried outusing an authentication device, the consumer firstly validates his/herpermission to use the authentication device 236. This primary validationtakes place locally (offline), between the consumer and theauthentication device, representing the first authentication of amulti-stage authentication approach to validating the right of theconsumer to use the authentication device in their possession. For thosemarkets or regulatory environments that require online verification, theservice will connect the relevant issuing institution through the system1 to the authentication device. The primary validation is by entry of arelevant multi-digit PIN and/or alphanumeric security code and/orbiometric authentication, employing a combination ofencryption/authentication standards, biometric recognition and 128-bitencryption methods, such as secure socket layers (SSL). Where a PIN isused, the PIN is mutually exclusive to any PIN associated with theconsumer's credit, debit, charge or prepaid cards, or other paymentmeans. The consumer may change the PIN, alphanumeric security code, orbiometric authentication method at any time through use of themaintenance process described above with reference to FIG. 9, which isaccessed via the authentication device or through secure access to theconsumer's account maintenance facilities via an Extranet. Both offlineand online security codes and, where utilized, biometrics can bemaintained using this facility.

If the consumer fails 238 to validate his/her permission to use theauthentication device after three successive entry failures of a PIN,alphanumeric entry code or biometric parameter, the authenticationdevice will be automatically disabled for entry of further details. Theconsumer will be required to contact a system operator to have his/herauthentication device unlocked and reset, and may be required toreregister his/her security details on the authentication device andwith the system operator or system 1, via, e.g. Extranet or IVR. Wherethe consumer wishes to use the system 1 before his/her authenticationdevice is unlocked and reset, the consumer will “fallback” to using theauthentication system 1 without an authentication device as describedbelow.

Secondary authentication 240 is performed either on-line by using theauthentication device to connect with the authentication server 10 oroff-line. For authentication in response to Internet or on-linetransactions, links to this step of the validation may be providedwithin a merchant's web page. On-line authentication is the preferredapproach, as this provides the most secure approach by allowing accessto the most recently available data. On-line authentication can beachieved by firstly using the authentication device to connect to theauthentication server 10 by Internet Protocol (IP) using one of (a) USB;(b) Firewire; (c) 802.11a/b/g wireless (“Wi-Fi”); or (d) Bluetoothconnectivity, and employing secure encryption techniques such as keyencryption or secure socket layers (SSL). Alternatively, connection canbe achieved by using mobile telephony services such as GPRS and 3G tocommunicate securely with the authentication server 10. These approachescombat anti-phishing and anti-fraud screen capture measures, providingincreased security. The authentication device can also be dynamicallyset to require regular on-line authentication, which further enhancesidentity and payment security. The mobile telephony service can also beused contemporaneously with Internet access, providing a furthersecurity benefit.

The secondary authentication 240 of the consumer involves verifyingconsumer identity or payment card(s) employing chip and PIN andcompliant with the Europay MasterCard Visa (EMV) validation standardsusing the EMV compliant chip reader 124 within the authentication device38. Any card used must be registered with the system 1 duringregistration of the account or using the account maintenance procedure.The card details are then compared with the details held within theconsumer's user record 54. User identity cards may be any cardsatisfying EMV chip and PIN standards such as specific user identitycards issued by the transaction system 1 operator or debit, credit,charge or prepaid cards. Where a card is not used to verify a consumeridentity, the consumer may elect to use a secondary on-line PIN and/oralphanumeric security code and/or password and/or biometric, which willbe encrypted and matched against a PIN and/or alphanumeric security codeand/or password and/or biometric identity which is pre-registered duringregistration or account maintenance. If the user fails the secondaryauthentication, contact with the service operator is required 242.

In the event that the secondary authentication step is successful, thethird and final authentication step is commenced 244. This isfacilitated by matching the authentication device identity tag, uniqueto the authentication device, with the cards, security codes, passwordand/or biometric combination linked specifically to named consumers andheld securely online on the central transaction system 1. The usersallowed to use an authentication device are specified duringregistration or account maintenance. Individual consumers are validatedagainst a unique authentication device tag if the authentication deviceis assigned to a sole user. If multi-user accounts are operated usingone or more authentication devices, validation is achieved by checkingfor a matching authentication device tag/account holder user identitycard combination as well as the multi-user identification/authenticationdevice tag combinations.

Where the consumer details are matched to the correct authenticationdevice 246, a check is done to see whether the consumer is in breach ofany operating parameters 248. If yes, the transaction is halted and theaudit files up-dated 250. If no, the consumer is fully authenticated andthe transaction continues 252. In contrast, where failure to match theconsumer's details occurs 256, for example, due to incorrect entry ornon-match of password, code, chip and PIN card details, biometric orauthentication device identity tag, the consumer is halted from furthertransacting using the authentication device. The consumer will then haveto use the account maintenance service or contact an operator to restoreuse of the authentication device, or to transact by using thenon-authentication device procedure described below. In all cases, thetransaction history of the user associated with the authenticationdevice is updated with details of invalid consumer transactions.

Optionally, for face-to-face transactions, the consumer may beauthenticated using a merchant's authentication device. This processinvolves the merchant triple authenticating themselves as describedbelow. Once the merchant has successfully authenticated its identity,the merchant will pass the authentication device to the consumer for theconsumer to authenticate their identity online. The consumer will beprompted to enter their identification code and PIN code and/or securitycode and/or biometric identifier. If these are valid, this will beconfirmed by an acknowledgement message being sent to the authenticationdevice from the authentication server 10, facilitating the next step inthe transaction process. If the consumer fails this first step inauthenticating their identity by three successive entry failures of aPIN, alphanumeric entry code or biometric, processing of further orderdetails will be halted. The consumer will be required to contact theoperator, and may be required to reregister their security details. Theinvalid user identity code is transferred to the audit trail logs by theauthentication server 10, and the transaction history of the merchantaccount associated with the authentication device is updated withdetails of invalid consumer transactions.

Where the first authentication step is concluded successfully, theconsumer dual authenticates their identity using a registered EMVcertified card (whether credit, debit, charge, prepaid or useridentification card) and PIN. In addition, the authentication server 10sends an on line challenge for third stage authentication by theconsumer, based either on a further EMV certified payment card if one isregistered to the consumer's account (e.g. where a user identificationcard was first used) or on the basis of pre-registered personal detailsor transaction histories. In this way, the consumer needs at least todual authenticate himself using the merchant's authentication devicebefore proceeding with a transaction. Where a consumer fails identityvalidation after three failed attempts at dual or tertiaryidentification, the authentication server 10 sends an appropriatereferral message to the authentication device, requesting the consumereither to use another registered EMV card/PIN combination or to contactan operator. Where the consumer has no further registered cards or aftera failure of three attempted EMV card/PIN combination entries,processing will be halted as a security measure. No further activitywill be allowed for that consumer using the card/PIN combinations usedagainst that authentication device. Transaction processing will behalted, and the appropriate merchant and consumer event and anti-fraudaudit logs will be updated.

Where an authentication device is not used, a dual authenticationprocedure 258 can be used by (a) interacting with an operator bytelephone after security validation is attained; (b) logging into theExtranet which will require at least dual authentication secure access,and validation and navigation capabilities as generally used forfinancial web sites, employing secure encryption techniques fortransaction processing; or (c) interacting with the IVR service. Primaryauthentication is achieved by providing a user specific password and/orsecurity details and/or PIN. Where there are multiple users of aconsumer account, the password and/or security details and/or PIN isspecific to the member of staff or individual user to enableaccountability. Secondary authentication is carried out using variousauthentication checks. These may include questions based on registrationdetails or transaction histories. The authentication checks used aredynamically varied, for example, according to an analytical algorithm toachieve best selection of questions to provide maximum security. If theconsumer fails authentication, re-validation of their identity isrequired through interaction with an operator 260. The consumer cannotthen process transactions until their registered identity details havebeen re-validated by the operator. The consumer account and audit logsare updated with the details of the failed authentication attempt. Wherea consumer passes identity validation, the process proceeds as before248-256.

Where the user is a merchant, the merchant registers staff members asauthorized users and assigns EMV compliant user identity cards, useraccounts and user PINs, passwords and/or biometric identifiers to themembers of staff. The permissions on each member of staff's user accountmay be selected upon registration or maintenance such that each staffmember has access rights and ability to use only the features of thesystem necessary to do their job. In this way, the merchant can controland segregate duties between staff members and control exposure toerroneous transactions, mistakes, staff acting out with their authorizedarea and fraud. The merchant may also specify that authentication iscarried out with an authentication device using triple authentication orwithout an authentication device requiring double authentication.

FIG. 13 shows the process for authenticating a merchant 262. If themerchant staff member is authenticating using an authentication device264, the staff member firstly authenticates their identity offline byentry into the device 266 of a relevant multi-digit PIN, alphanumericsecurity code or biometric authentication, employing a combination ofEMV authentication technology (e.g. chip and PIN), biometric recognitionand 128-bit encryption methods as generally available. Where a PIN isused, the PIN is mutually exclusive to any PIN associated with anymerchant's or staff member's identity or merchant personal EMV compliantcards. One or more authentication devices may be uniquely linked to oneor more authorized members of merchant staff

The list of staff members authorized to use an authentication device maybe updated using the account maintenance facilities. Updated user listsare communicated to the authentication device 40 from the authenticationserver 44 via an appropriate communications channel such as an Extranet,GPRS, Wi-Fi, 3G mobile communications, etc. Authentication is achievedby comparing the identity as indicated by the identity card andassociated PIN, security code, etc. with the list of valid users storedon the authentication device. The merchant may change the PIN,alphanumeric security code, or biometric authentication method at anytime through use of the maintenance facility using the authenticationdevice directly or through secure access to the merchant accountmaintenance facilities via the Extranet. Both offline and onlinesecurity codes and, where utilized, biometrics can be maintained usingthis facility. Validation of the merchant identity with theauthentication device is a prerequisite to transacting using theauthentication device.

If the merchant member of staff fails to validate their identity 268after three successive entry failures of a PIN, alphanumeric entry codeor biometric, the authentication device will be automatically disabledfor entry of further details as a security measure. The merchant will berequired to call an operator to have its authentication device unlockedand reset, and may be required to reregister its security details on theauthentication device and on the authentication server 44. No furthertransactions can be processed using the authentication device 40 untilit is unlocked, and potentially re-registration has taken place. Similarrestrictions apply whether or not a merchant has a single or multipleusers of an authentication device 40. Where the merchant wishes to usethe service in the event that an authentication device is locked, themerchant may fallback to using the authentication service without anauthentication device 40 as described below.

If the merchant member of staff successfully completes the firstauthentication step, the staff member must then carry out two morestages 270, 272 to authenticate their identity. The staff member doesthis by firstly 270 using the authentication device to connect with theauthentication server 10. This can be achieved by connecting by InternetProtocol (IP) as a transport for transactions generated by theauthentication device using one of (a) USB; (b) Firewire; (c) 802.11a/b/g wireless; or (d) Bluetooth connectivity, as generally available,and employing secure encryption techniques such as key encryption andSSL. Alternatively, connection can be achieved using mobile telephonyservices (e.g. GPRS, 3G) as generally available, to communicate securelywith the authentication server 44. Both approaches include anti-phishingand anti-fraud screen capture measures as are known in the art. Themobile telephony service can also be used contemporaneously for Internet(IP) access, providing a further security benefit for merchants incountering identity theft and payment fraud.

Secondary authentication 270 of the merchant staff member is thereafterfacilitated by verifying merchant staff member identity card(s)employing EMV compliant chip and PIN validation techniques against theEMV compliant chip reader within the authentication device. Any identitycards used must be registered and match details held within themerchant's account. Other cards that satisfy EMV chip and PIN standardsand common criteria could be used (e.g. specific to merchant) but wouldrequire to be registered and validated to maintain security levels. Inthe event that the merchant fails this stage, they are required tocontact the service operator 273. In the event that the merchant passesthis stage, they move onto to third authentication stage, 272. This isfacilitated by matching the identity tag unique to the authenticationdevice with the cards, security codes, password and/or biometriccombination used by the merchant member of staff and held securelyonline on the transaction system 1. This is a further unique securityaspect, requiring merchant PINs, security codes, passwords, cardidentity details, and authentication devices identity tags to be linkedspecifically to named merchants and pre-registered staff held andregistered on the transaction system 1. As before, if the merchant failsthis stage, they are required to contact the service operator 273.Otherwise, they move onto the next stage 274. This involves a check ofwhether the merchant is in breach of its operating parameters and/oragreed service limits. If yes, the transaction is halted and thetransaction and audit files up-dated 276. If no, then the transactionproceeds 278.

In an optional embodiment, for face-to-face transactions the merchant ormerchant staff member may be authenticated using a consumer'sauthentication device. All parties must be registered users of theservice. In this process, the consumer is firstly authenticated asdescribed above. Once successfully authenticated, the consumer isinstructed via instructions displayed on the authentication device topass the device to the merchant member of staff. The merchant member ofstaff then inserts their identity card into the consumer'sauthentication device. Primary authentication is achieved utilizing EMVauthentication standards such as chip and pin. Secondary authenticationis via the input of a pass code or 2nd PIN and optionally answering ofappropriate dynamically selected challenge questions selected accordingto an analytical algorithm. Authentication is carried out online,thereby increasing the security of the authentication process.Individual merchant staff are separately identified by specific identitycards and pass codes or PINs that are unique to the member of staff.

If a merchant fails authentication during secondary or tertiaryauthentication (e.g. invalid identity, invalid pass code or securitydetails), merchant re-registration will be required, through merchantinteraction with an operator. The merchant member of staff involvedcannot process transactions until their registered identity details havebeen revalidated. In instances where validation fails, requiringre-registration, two further merchant staff with appropriate accesscapabilities may attempt validation, in which case the process isrepeated with a different merchant member of staff using a differentidentity card and pass code. If other members of staff do not haveappropriate access permissions, processing will halt, and the audit logswill be updated with the details of the transaction. Communication ofthe authentication failure to the consumer is the responsibility of themerchant, as the operator will not be aware of the consumer's orderbeing received by the merchant. If consumers contact the operator withdetails of the merchant, the operator can investigate the rejection.

Where an authentication device is not used, a dual authenticationprocedure is used 280 by (a) interacting with an operator by telephoneafter security validation is attained; (b) logging into the Extranetwhich will require at least dual authentication secure access, andvalidation and navigation capabilities as generally used for financialweb sites, employing secure encryption techniques for transactionprocessing; or (c) interacting with the IVR service. Primaryauthentication is achieved by providing a user specific password and/orsecurity details and/or PIN. Where the user is a merchant staff memberor where there are multiple users of a consumer account, the passwordand/or security details and/or PIN is specific to the member of staff orindividual user to enable accountability. Secondary authentication iscarried out using various authentication checks. These may includequestions based on registration details or transaction histories. Theauthentication checks used are dynamically varied, for example,according to an analytical algorithm to achieve best selection ofquestions to provide maximum security. If the merchant failsauthentication 282 (e.g. invalid user identity, invalid password orsecurity details), they are required to re-validate their identitythrough interaction with an operator. The staff member cannot thenprocess transactions until their registered identity details have beenre-validated by the operator. The merchant account and audit logs areupdated with the details of the failed authentication attempt. If themerchant passes authentication, then the procedure is as before 274-278.

FIG. 14 shows a process for pre-order validation of a merchant'sidentity. This allows the consumer to establish if a merchant is avalid, trusted user that is currently transacting within its authorizedservice agreement. This affords the consumer a significantly increasedlevel of confidence and security in transacting with merchants of whomthe consumer has previously had no experience. In some transactiontypes, for example face-to-face purchases, it is less likely that theuser will want to pre-validate the merchant's identity, as purchases aregenerally made on impulse. However, this feature may still be usefulwhen purchasing high value items such as jewellery, high valueelectrical goods, cars or furniture, or the goods are purchasedface-to-face but delivered later.

To facilitate validation of a merchant's identity 284, the merchantsupplies the consumer with the merchant's identity code 286, which maybe displayed on, for example, the merchant's web page, in a shop, in acatalogue, promotional literature or communicated by sales staff over aphone line or face-to-face. To pre-validate the merchant, the consumertransmits the merchant's identity code to the authentication server 10.The merchant identity code is then checked against valid, activemerchant user records held on the transaction system 288. Where themerchant identity is found to be invalid or suspended, the consumer willbe informed/alerted 290. The consumer and, where appropriate, merchantaccounts will be updated accordingly, as will the appropriate audittrail log files. Until a valid merchant identity is authenticated andacknowledged, the consumer takes no further action. Interaction betweenthe consumer and an operator may take place to investigate the invalidmerchant details. Where the merchant identity is found to be valid, theconsumer will be informed/alerted 292 and the transaction can proceed.

Once the merchant has been validated as genuine and operating within itsservice agreement, the order may be logged with the transaction system1. Logging details of an expected order with the transaction system 1before placing the order with the merchant allows the expected order tobe crosschecked against the order the merchant actually processes. Theconsumer firstly selects which payment means they wish to use in thetransaction. Once the transaction server 1 matches the transactionssupplied by the consumer and the merchant, the payment server of thetransaction system 1 uses the specified payment means to effect paymentto the merchant. No details of the payment means are ever communicatedto the merchant. Thus, not only is the method of payment distinct andmutually exclusive from the method of achieving identity verificationbut unlike existing payment methods, no source payment account detailsare ultimately available to the merchant, enhancing identity and paymentsecurity for consumers. As an extra security feature, each paymentaccount can be stipulated for use only with certain transaction types,e.g. mail, telephone, face to face or Internet order and for othertransaction parameters such as use only with certain merchants and/ortransactions up to a certain limit and/or for certain types of goods,etc.

During registration certain accounts may be selected as default accountsfor certain transactions. For example, the consumer may specify that aparticular credit card be used for all Internet based transactions, anda particular debit card be used for all person-to-person transactions.Alternatively, a single account may be specified for all transactions.In any case, default accounts, where registered, may be confirmed oroverridden only with other previously registered accounts, providingfurther security. Where the consumer wishes to override pre-selecteddefault accounts, a secondary password/security code is required if anauthentication device is not used, such as when using telephone, IVR orExtranet. Where an authentication device is used, non-default over-rideaccounts, whether card or non-card, can only be selected after onlineverification of an override PIN, alphanumeric code or biometric. Theauthorization server will prompt for confirmation of selectednon-default over-ride accounts. Only previously registered accounts maybe selected in favor of default accounts. Where an over-ride accountselection fails verification, the consumer is notified in accordancewith their preferences, and the system falls back to the default accountchoices previously registered.

Where no default accounts have been previously registered, the consumermay register a new account through the maintenance facilities, whichwill result in processing of the order being halted until this is done.Where a valid, pre-registered default or over-ride account is selectedand confirmed, the transaction value, an address code selected fromthose updated during consumer registration or maintenance, and anoptional narrative description of the goods are supplied to complete theorder pre-validation. At this point, both consumer and merchant accountsare updated for the order, within an “awaiting order” status.

The order data stored against a consumer record is compared to anysubsequent order lodged by the merchant upon order fulfillment. Unlessany subsequent order logged by a merchant matches the order detailsprovided by the consumer, the transaction will be placed on hold andboth consumer and merchant notified. It is then up to the consumer andmerchant to rectify the discrepancy as appropriate. The transaction willremain on hold until released by the consumer. This provides extraconfidence to the consumer that any orders match the requirements of theconsumer before any payment is made and lowers the cost of returns andminimizes complaints rates for merchants. This procedure may be waivedin certain retail situations such as face-to-face purchases where thegoods are generally provided instantly to the consumer. However, even inthese cases, this procedure may still be used in appropriate situations,for example, if the goods are ordered face-to-face but delivered orsupplied later.

As noted previously, the placement of orders by consumers can be madeusing a range of transaction types, e.g. mail order, telephone order,face-to-face or Internet order. Regardless of the transaction type, theconsumer generally orders goods by validating the merchant's identity,and authenticating themselves as described above. Then details of anexpected order are logged and the order is placed. Communication withthe transaction system 10 may be via any of the communications routesdescribed previously, for example by using an authentication device,Extranet, via telephone to an operator or IVR, mobile communicationssuch as WAP, 3G or i-mode or by Wi-Fi. However, regardless of thetransaction type or communication channel used, because of the basicprinciple of separation of authentication and payment, the same securitylevels can be applied across all payment channels.

Once the merchant receives the consumer's order, the merchant mayprocess the order by accessing the transaction system 1 using one of thecommunications methods such as using an authentication device, Extranet,by telephone to an operator or IVR or mobile communications. Thereafter,the merchant is required to authenticate their identity using tripleauthentication if an authentication device is being used or by doubleauthentication otherwise, as described above. After the merchantidentity is authenticated, to access the system, the merchant must thenvalidate the consumer's identity and address codes, as shown in FIG. 15.This feature serves to reduce the levels of consumer identity theft andgives the merchant an increased level of confidence in transacting withconsumers of whom the merchant has no previous experience. The merchantcarries out consumer identity and address validation by interacting with(a) the operator by telephone; (b) the Extranet secure processingservice (utilizing SSL 128-bit security encryption or better asgenerally available); (c) the IVR (Integrated Voice Response) service,to provide details by voice or by using the telephone keypad; or (d) avalid authentication device 40 to enter details. Merchants using theExtranet system will require to use a selection of mouse selection,alphanumeric character recognition and different web pages to improvesecurity. The merchant may use the authentication device 40 as an inputdevice to send encrypted data using generally available mobile telephonyservices to the transaction system 1 and gain acknowledgement in return.

FIG. 15 shows part of the order process, which serves to validate theconsumer 294. The merchant obtains an identity code and an address codefrom the consumer. The merchant communicates the consumer identity codeto the authentication server 296. The authentication server checks theconsumer identity code against the user records on the storage media andreturns an indication of whether or not the consumer identity is valid.If the consumer identity code entered by the merchant is invalid andfails a pre-specified number of repeated attempts at entry validation,the order entry transaction halts and the merchant is referred back tothe consumer with the option of receiving further details by contactingan operator 298. The transaction logs of both the consumer and merchantare updated along with the consumer and merchant audit logs 299.Progress to the next stage of input of the address code is dependentupon successful validation of the consumer identity code.

Where the consumer identity is valid, the address code can then becommunicated to the authentication server 300. The authentication serverchecks that the supplied address code matches an address code stored inthe consumer's user record. If the address code is invalid (i.e. doesnot match a stored address code) and remains invalid after failing apre-specified number of repeated attempts at entry validation, theauthentication server will refer the transaction back to the merchantand additionally alerts the consumer using the preferred notificationroute recorded on the consumer's user record 302. If either the consumeridentity code or the address code is invalid, the invalid consumerdetails are transferred to the anti-fraud audit trail logs 303. Themerchant account transaction history is updated with details of theinvalid consumer transactions with appropriate status codes. Theconsumer account transaction history is also updated. If the merchant isprocessing multiple consumer orders, processing will flow to the nextconsumer identity transaction.

Optionally, in some circumstances, the consumer can upload their orderdetails onto the transaction system 1. If the consumer does this, thetransaction system 1 matches the consumer identity code, address codeand merchant identity code to those supplied in the preloaded details inorder to further validate the order and merchant identity during initialorder processing. The matching of consumer and merchant transactions isan improved counter-fraud security validation check. Where the matchesare valid, processing moves to the validation of the consumer paymentdetails.

FIG. 16 shows a process for validating consumer payments. This allowsthe merchant to pre-check the consumer's ability to pay and istransacting normally. Validation of consumer payments prior to dispatchor handing over of goods minimizes the risk of non-payment to themerchant and provides an increased level of confidence in transactingwith new customers. Checks performed by issuers of payment cards foravailability of funds do not, where identity is breached, providefurther identity security. The validation process described hereinprovides, in addition to its triple authentication approach, additionalchecks against pre-registered payment preferences for consumer-preferredchannels, types or values of payment, as well as volume and transactionvelocity checks. These checks differ from the authentication means used,providing separation of authentication and payment.

To validate consumer payments, the merchant provides the transactionsystem 1 with further details of the consumer order/transaction 306. Thesystem 1 matches the transaction details with those uploaded by theconsumer and determines which consumer payment means 47 is to be used.If the consumer did not elect to upload order details (includingspecifying which payment means to use) prior to contacting the merchant,the payment account selected will default to the payment means nominatedby the consumer during registration/maintenance. Once the payment meansis identified, checks can be performed by liaising with the consumeraccount/service providers 2 a-c during transaction entry, for example toestablish funds availability and status of the consumer payment accountto be used 308. The transaction system 1 may facilitate these servicesby acting as a third party trusted processor, merchant aggregator,reseller or independent sales organization (ISO) as appropriate, in linewith the appropriate payment association classifications. If theconsumer issuer payment validation is successful, then a service paymentvalidation is carried out 310.

Transactions that fail any specific issuer validation check will benotified to the consumer and a referral/service review initiated 312.Processing is halted on the consumer transaction. If the merchant isbulk processing multiple consumer orders, processing will flow to thenext consumer identity transaction. Where transactions are not referredby payment issuers, additional checks are made by the transaction system1 to compare and validate the payment against the consumer's operationalparameters such as for payment type, value, transactionfrequency/velocity and bulk spend in a consumer-predefined period thatare stored against the consumer's account during registration or accountmaintenance. The transaction system 1 may compare the transactiondetails, along with transactions from the consumer transaction log whereappropriate, with the preferences and limits stored on the consumer'saccount. If a transaction would result in a breach of operationalparameters, the transaction is referred back to the consumer using thereferred transactions procedure 314. This may include a review of theconsumer's status and activity. Processing is halted on the consumertransaction. If the merchant is bulk-processing orders for multipleconsumers, processing will flow to the next consumer identitytransaction.

For valid transactions that are not stopped by issuer or consumerreferrals, additional merchant validation checks 316 are applied by thetransaction system 1, irrespective of the method utilized by themerchant for communicating with the transaction system 1. These merchantvalidation checks are necessary to ensure that the merchant keeps withinits operational parameters, such as value, transaction volume,frequency/velocity and level of complaints, agreed and authorized duringthe merchant registration or subsequent merchant account review oraccount maintenance. Where breaches of merchant operational parametersoccur, the transaction system 1 may either restrict merchanttransactions or allow the merchant to fulfill the transactions processedwith appropriate retention of settlement for payments until themerchant's transaction activity is brought back within the operationalparameters or new operational parameters are agreed and authorized. Themerchant will be referred to an operator to review 318 its serviceagreement, for example to negotiate different agreement limits,regardless of whether transactions are allowed or halted. Whether atransaction is halted or allowed will depend upon, respectively, whetheror not shadow limits have been breached.

Where merchant processing is halted, the merchant is notified andfurther transacting with the merchant suspended until the merchantrectifies the reason for the breach of operational parameters, or agreesa change to, its service agreement terms and/or operational parameters320. The merchant is then responsible for communicating the delay inprocessing to the relevant consumer, as the rationale for restrictingtransactions is linked to the merchant commercial terms with the serviceoperator. The transaction system 1 will additionally send a notificationto the consumer that transactions are halted, in accordance withconsumer notification preferences. Updates to the merchant and consumertransaction logs are made, together with updates to the audit traillogs, tagged with appropriate status codes, which indicate the status ofthe transaction, for example “transaction halted: merchant limitbreach”. Every transaction has a status code until it is completed. Nofurther activity on the consumer transaction causing the merchant breachtakes place. A new transaction will require to be processed where themerchant breach of operational parameters is not rectified.

If the merchant validation checks are satisfactorily completed,acknowledgement is provided in real-time by the transaction system 1 tothe merchant as appropriate 322. A unique transaction identifier isassigned to the validated transaction. Additional acknowledgement can beprovided in the form of automated SMS text message, either pertransaction or at end of day for consolidated transaction details. Themerchant will be required to respond to an SMS message with a predefinedpassword set at registration before the acknowledgement is transmitted.Historic merchant acknowledgements are stored on the merchant'stransaction log and can be reviewed by the merchant by interaction withthe transaction system 1. The consumer is also notified of the completedmerchant transaction using the notification procedure.

Finally, merchant and consumer transaction histories, and relevant audittrail logs are updated. Subsequent transactions are processed until allconsumer orders are processed. If the merchant is processing bulk ordersfor multiple consumers, processing will flow to the next consumeridentity transaction. Processing of valid merchant transactions is nextdirected to the consumer acceptance/rejection process, which allows theconsumer to confirm that they did place the original order and that theyaccept the dispatch of goods/services from, and payment to, themerchant. This extra check at this advanced stage in the order processprovides increased end-to-end security against payment fraud andconsumer and merchant identity theft. In order for fraud to occur,multiple security breaches and checks would require to be compromised.

Within the notice of the completed merchant transaction, the consumer isprompted to respond to accept or reject the merchant processedtransaction by providing details of the order via the notificationsystem, and then to confirm their choice, to ensure single-attempttransaction entry errors are minimized 324. The consumer may,alternatively, elect to trust validated order transactions, in whichcase a transaction acknowledgement will be sent. Specification of whichtransactions to trust is set during consumer registration or accountmaintenance. In the event of discrepancies, the consumer may contact anoperator to obtain more details of the transaction.

Where the consumer elects to reject a merchant order transaction, thespecific order transaction concerned will be halted and the transactionstatus will be changed to “consumer rejected”. No further activity istaken to settle the transaction between consumer and merchant. Where theconsumer accepts the payment transaction, the transaction status will beset to “awaiting fulfillment”. Relevant merchant and consumertransaction and value limits will be updated for “awaiting fulfillment”transactions, to ensure that early warning is registered of potentialbreaches. The merchant is then notified by the transaction system 1 toproceed with order fulfillment. Thus, before the merchant can dispatchgoods/services to a consumer the following security steps must becompleted: Successful authentication of the merchant identity;successful authentication of the consumer identity; successfulvalidation checks that the merchant and consumer are operating withintheir service preferences and limits; validation of the consumer paymentmeans; and confirmation from the consumer that they accept thetransaction as valid and wish to proceed. This combination of securitymeasures provides a safeguard for both the merchant and consumer beyondlevels provided by prior art payment systems, and can advantageously beapplied over multiple transaction channels.

Once the merchant has goods ready to ship to the consumer, the shippingprocess can be engaged. This may occur contemporaneously with orderprocessing and validation, or take place some time after, depending onthe availability of goods and with predefined segregation of duties ofmerchant staff for added security. Validated order transactions will beheld on the transaction system 1 with “awaiting fulfillment” statuscodes. Before starting the order fulfillment process, the merchant orstaff member must authenticate their identity using the tripleauthentication process if an authentication device is used or the doubleauthentication process without an authentication device. During accountregistration, merchants can elect to segregate each merchant staffmember's ability to process and fulfill the same orders. This can bedone by individual registration of merchant staff users, theirauthentication devices if applicable, their user identity cards and thefunctions to which they have access.

As shown in FIG. 17, once both merchant and/or relevant merchant staffare authenticated (notwithstanding they may already be on line and notsubject to predefined segregation of duties for added security), themerchant (or merchant staff) may access those order transactions flaggedwith a status of “awaiting fulfillment”, from the transaction system 1.The merchant identifies the transaction(s) to be processed for paymentby their account details and order transaction reference(s), whichadditionally identifies the channel of origin, for example mail,Internet, telephone. Only transactions with an “awaiting fulfillment”status are made available to the merchant by the transaction system 1.Referred transactions will be held in an appropriate queue tagged with a“referred transaction” status.

The merchant will be prompted by IVR, operator, Extranet orauthentication device prompt, to acknowledge the merchant is ready todispatch the goods concerned. This facilitates card scheme requirementsto take payment only on dispatch of goods, providing an additionalcompliance check. The merchant then accesses the orders that areawaiting fulfillment 330 and determines whether the orders can be whollyor partially fulfilled 332. Where goods are partially available fordispatch, the merchant contacts the consumer to determine whether theconsumer wishes to accept delivery of the partial order or whether theywould prefer to wait 334. The request is made via the notificationsystem. The consumer can then respond accordingly via the transactionsystem 1. The consumer may also default to await fulfillment of completeorders or accept partial fulfillment at registration or through accountmaintenance. Where (i) the merchant does not have the goods to fulfillthe order; or (ii) the consumer declines partial fulfillment, or (iii)the consumer accepts partial fulfillment, for those goods that cannot befulfilled, the transaction status of the order remains at “awaitingfulfillment” 336 and no further action is taken on that order until thegoods are ready for dispatch to fulfill the consumer order. Where themerchant has one or more further transactions to process, the system 1will direct the merchant to the next order with transaction status“awaiting fulfillment”.

Once the merchant has acknowledged readiness to dispatch goods (whetherfull or partial orders), and the consumer order is wholly fulfilled, orpartially fulfilled with consumer acceptance, a check is performed toassess whether the initial processing of the order is over a specifiednumber of days old, defaulted to five days at registration (andspecified further in the merchant service agreement) 338. Where theorder has been unfulfilled for at least this period, the transactionsystem 1 re-validates the consumer identity 340 and payment details toensure the payment can proceed before goods are dispatched 342. Thissecurity check ensures that merchants are not overtly exposed to fraudthat may have occurred during the delay between the payment transactionand completion. The transaction system 1 firstly re-validates theconsumer's identity and address code as described above, to ensure itremains active and does not have a “lost/stolen” or other securitystatus recorded. If the consumer identity and address code arerevalidated, the transaction system 1 next revalidates the relevantpayment means for funds availability and notification statuses.

The consumer can select to automatically trust transactions in theiroperating parameters. If transactions are automatically trusted then theaged transaction status is then updated to “awaiting addressconfirmation” and the merchant is notified. Where a consumer has notpreviously elected to automatically trust a transaction, the transactionsystem 1 reconfirms that they want the order to be fulfilled or rejected344. Once this is done, the merchant dispatches the goods and the orderis fulfilled 346. The merchant cannot fulfill orders prior to acceptanceby the consumer, as the consumer address has not been passed by thetransaction system 1 to the merchant. In this way, additional securityprotection is provided to both consumer and merchant.

FIG. 18 shows the steps for accepting and/or rejecting an aged paymentin more detail. Firstly it is determined whether the consumer haselected to trust the transaction without validation 350. Where theconsumer has not previously elected to trust transactions and acceptfulfillment of orders processed without further validation at the orderfulfillment stage, the consumer is prompted to respond to a notificationrequesting the user to accept or reject the delayed transaction and thento confirm his/her choice, to ensure single-attempt transaction entryerrors are minimized 352. Where the consumer does not trust transactionsand subsequently rejects the order 354, the merchant will receive a“consumer rejection” transaction notification from an operator, IVR,authentication device or Extranet communication. The transaction willhalt and the merchant and consumer account transaction logs will beupdated. No further transaction processing will take place on therejected transaction. Audit-trail and rejected transaction records, andthe merchant transaction volume and value limits will be updated. Wherethe consumer accepts the revalidated order, the merchant will receiveacknowledgement 356 by service agent, IVR, authentication device orExtranet communication that the transaction has been successfullycompleted. The transaction status will be updated to “awaiting addressconfirmation”. The transaction system 1 updates the consumer andmerchant accounts for the status of the transaction (whether completedsuccessfully or rejected) and tracks transaction stages and transactionstatus accordingly 358. Transactions will have a “awaiting addressconfirmation” or “consumer rejected” status.

Once all checks are successfully completed, the merchant can fulfill theorder 360, as shown in FIG. 19. For those transactions with a status of“awaiting address confirmation” only, the consumer's delivery addressdetails are passed to the merchant for order fulfillment 362. Thus, theconsumer address is withheld from the merchant until the order is on thepoint of dispatch and all authentication steps have been completed. Inaddition, the delivery address may be different from the billingaddress. This is beneficial in reducing the accessibility of consumerdetails and thereby reducing the risk of identity theft. The consumer isnotified of the dispatch of goods by a notification message 364. In thisway, the consumer has a final notification of the transaction beforedispatch of the goods, which allows the consumer a further chance toreport any unexpected orders and thereby reducing fraud. The transactionsystem 1 updates the consumer and merchant accounts to “completed”transaction status. Relevant merchant transaction and value limits willbe updated for completed transactions, to ensure that early warning isregistered of potential breaches 366.

The transaction system 1 communicates with the issuer of the consumerpayment means selected for that transaction and facilitates the transferof funds to the merchant directly into its predefined bank account 368.In an alternate embodiment, the transaction system 1 can arrange for thetransaction funds to be obtained and held in escrow by the system 1before the goods are dispatched by the merchant. Once the funds are inescrow by the system 1, the system notifies the merchant. The merchantmay then dispatch the goods, with the funds being transferred by thesystem 1 to the merchant's predefined bank account when the goods arereceived by the consumer. This gives the retailer a guarantee of paymentand the consumer a guarantee that they will receive the goods beforepayment is received by the retailer. Any chargeback reserve or retentionfund assessed prudent by the system operator or in accordance with themerchant service agreement will be withheld until the merchant meetsspecific contractual terms.

FIG. 20 shows the process for handling referred consumer transactions.Each user account has certain operational parameters within which theaccount must be operated. The operational parameters are either set bythe service operator when issuing accounts or during a user review,based on an assessment of the risk of the user in order to minimizeexposure of the service operator to fraud and bad debts, and/or selectedby the user themselves on registration or account maintenance to limittheir own exposure to fraudulent use or to help control their owntransaction patterns. As shown in FIG. 18, referred transactions aretransactions that fail to meet these operational parameters or arereferred by a user's payment issuer is response to a breach of limitsset by the issuer. Since changing of the operational parameters is viaaccount maintenance, which requires the user to dual or tripleauthenticate themselves, it is considerably more difficult forfraudsters to alter user account settings and thereby reduce thepossibility that fraudulent transactions can be approved. The greaterthe use of these criteria, the more effective the referral processeswill be. Consumer security and convenience are therefore emphasized.

Consumer transactions may be referred either by the transaction systemor by the institution providing the consumer with a card or account fora number of reasons. When a referral is made, it is firstly determinedwhether it was by the system 1 or the issuer 372. Where it is theissuer, referral can be for a number of reasons, e.g. insufficientfunds, temporary hold on account, lost or stolen card, type of merchant,value of transaction. Payment card and non-card payment meanstransaction validation checks are performed during transaction entry, inline with existing payment provider checks, to establish fundsavailability and status of the registered consumer payment account beingused. The transaction system 1 may facilitate these validation checksdirectly or through access to payment provider services by acting as athird party trusted processor, merchant aggregator, reseller orindependent sales organization (ISO) as appropriate, in line with Cardsand non-Cards payment association classifications. When a card ornon-card payment account breaches a predefined referral check, a formalcard, or non-card issuer referral is activated, in line with card schemeor non-card payment means provider regulations. In addition, consumeroperational parameters may be breached that trigger a referral by thetransaction system 1 that halts or delays a consumer's ability to pursuea transaction further. The operational parameters include, for example,checking for breach of limits on payment type, value, transactionfrequency/velocity and bulk spend in a consumer-predefined period.

Where a consumer's payment means issuer (e.g. Visa, MasterCard) refers374 a transaction to the transaction system 1, the transaction system 1will notify the merchant automatically 376. The merchant will benotified of the referral status of transactions by the interaction routebeing used to process the consumer payment transactions, e.g. by IVR,service agent by telephone, Extranet or authentication device. Themerchant will notify transaction referral to the consumer during theordinary course of the transactions, as referrals necessarily hold uppayment completion progress 378. For consumer order transactions,notification is also made using the notification system. This approachshould ensure appropriate notification to the consumer is effected,alerting the consumer to any transaction issues of which they should beaware. Where a referral has occurred due to the consumer breaching oneor more predefined operating parameters, the consumer is requested tocontact an operator for a service review. Assessment of the referredtransaction against shadow limits will determine whether a transactioncan be processed to conclusion. Shadow limits will be set atregistration and will be applied by the transaction system 1 to alloworderly management of consumer use of the service. This enables theconsumer to have control over the value and velocity of theirtransactions.

Where a transaction is allowed within the shadow limits, the referredtransaction is processed to conclusion. The relevant user is notified bya notification and the consumer may be requested to seek a servicereview. Where the transaction system 1 does not allow a transaction toproceed to conclusion, for example, where a shadow limit is breached oran issuer referral has occurred, both the merchant involved and theconsumer are notified by the notification system. The paymenttransaction will be halted, and its status set to “halted” 380. Thetransaction system 1 will take no further action on the transactionuntil the merchant and consumer have placed a further transaction thatis not referred. Additionally, the merchant and consumer transactionrecords will be updated to reflect the transaction status. The audittrail logs are updated with details of the transaction.

As shown in FIG. 21, in particular instances, a consumer may reject atransaction 384. This may take place where the consumer is unaware thetransaction has been made, for example fraud or misuse, but the existingcard or bank account systems used by the consumer have not been alertedto the activity. It may also be due to “cooling off” legislation, whichallows consumers to repudiate transactions in particular circumstancesand hand back goods. Where the consumer rejects the transaction, andselects an appropriate reason code for transmission, the transactionwill be halted 386. The consumer may also reject a pending transactionthat has yet to be fulfilled, due to merchant delay, before the merchantacknowledges readiness to dispatch the order. The consumer will do thisby processing a rejection transaction through a valid, secureauthentication device, Extranet or by direct telephone call. SMS oremail will not be valid formats for processing consumer initiatedrejection transactions as since these transactions are consumerinitiated, the options to provide authentication using these channelsare limited. No further activity on the transaction will take place. Nogoods will at this stage have passed from the merchant to the consumer,and the status of the transaction should remain at “awaitingfulfillment”. The consumer may reject the transaction even afteracceptance during initial transaction validation if a valid reason codeis entered. On receipt of a valid consumer rejection transaction, themerchant concerned will be notified by the notification system 388.

The merchant and consumer transaction logs will be updated accordingly390 and the audit trail logs will be updated 392. System operators canthen investigate the transaction and engage transaction monitoringsystems to identify whether fraudulent or abnormal activity is takingplace with the consumer and merchant concerned.

In view of the unique additional security aspects offered by thetransaction system 1, the probability of chargebacks due to fraudulenttransactions will be significantly reduced, enhancing convenience andsecurity for consumers, and reducing fraud risk, costs andadministration for merchants. Nevertheless, provisions are made fordoing this as shown in FIG. 22. Chargeback transactions originate fromissuers of credit and charge card products who have been legitimatelyinstructed by consumers who wish, for varying reasons, to reverse apayment transaction previously made, generally due to dispute. Thetransaction system 1 will process chargebacks 394 against registeredmerchants in line with credit card association rules for credit cards,for example, where a consumer claims goods purchased were not receivedor where the item purchased is “not as described” by the merchant. Otherpayment provider chargeback rules will also be honored. Theauthentication, notification service and other security aspects resultin reduced probability of chargebacks due to fraudulent transactions,enhancing convenience and security for consumers, and reducing fraudrisk, costs and administration for merchants.

A consumer requiring a chargeback to be made sends a chargeback requestto the transaction system 1 directly for service transactions, orthrough the consumer's issuing institution for other transactions, wherethe system acts as a merchant aggregator or ISO. The system is checkedto see whether the chargeback is recorded 396. Details of thetransaction to be charged back are matched against the consumer andmerchant transaction records and validated against legitimate chargebackreason codes 398. This prevents consumers mistakenly or fraudulentlyobtaining chargebacks on transactions that have not actually occurred orfor invalid reasons. Where the chargeback request is unsupported, nofurther action is taken, and the consumer and merchant transaction logsand audit and chargeback logs are updated accordingly 400. The system 1will transfer the relevant transaction details onto the audit logs tofilter against future chargeback attempts involving the same consumer ormerchant.

Where a chargeback request is valid, both the merchant and consumeraccounts are updated with the chargeback details and reason codes inaccordance with general industry practice 402. The chargeback log willalso be updated. The transaction concerned will be charged back againstthe merchant's account or chargeback reserve as necessary whilstchargeback dispute resolution takes place. The transaction system 1 willpass details to the merchant's bank or payment institution concerned,and thereafter liaise 404 with the merchant's bank/institution and theconsumer's bank/institution as necessary. For non-card transactions, theoperator liaises with the banks/institutions representing the consumerand the merchant as necessary.

In instances in which resolution to a chargeback dispute is required,merchant and consumer service terms and conditions will dictate whichparty bears the liability for the value in dispute 406. This will befacilitated through service agreement reviews. This review may result insuspension of particular merchants or consumers from use of the servicedue to excessive chargeback histories, velocities or value parametersbeing breached. During “suspended” periods, merchants or consumers mayonly access registration and maintenance facilities. No paymenttransactions can be processed. Chargeback dispute resolution may resultin merchant funds being withheld whilst a chargeback dispute isinvestigated to conclusion. Dispute resolution may result in a refund tothe consumer from the merchant, or validation of the disputedtransaction in favor of the merchant 408. The relevant consumer andmerchant accounts will be updated on completion of the chargebackdispute. Dispute resolution will be communicated to the users concernedvia the notification system 410.

In some instances, for example, where an error is made and accepted by amerchant, e.g. processing error, or goods are legitimately returned orexchanged, a credit transaction may be required to reimburse, in full orin part, the consumer. In such cases, the merchant can process a creditusing the transaction system 1. FIG. 23 shows the steps for processingcredits. Credits may be issued to consumers mistakenly or fraudulentlyby members of the merchant's staff. In order to minimize this, theservice matches credits to underlying transactions and if they are notmatched, presents additional security levels to validate the credits. Inaddition, merchant check criteria may be set and permissions only givento certain members of merchant staff, for example to authorize largevalue credits, as defined on registration or account maintenance, orcredits that do not match underlying transactions.

Where a credit transaction is initiated 414, the merchant may onlyprocess the credit against a completed transaction. In order to processa credit the merchant and merchant member of staff must undergo thedouble or triple authentication process. As described previously,merchants can elect to improve security over potential fraud bysegregating the ability to process order transactions and subsequentcredit transactions against those orders amongst different merchantstaff by registering different merchant staff as users, theirauthentication devices if applicable and their identity cards andassigning their access only to certain transaction system 1 functions.Once the merchant staff member identity details are validated 416,details of the transaction to be credited back are matched against theconsumer and merchant account records 418.

Where the credit cannot be matched partially or fully against apreviously completed transaction, no further action is taken unless themerchant further authorizes the credit 420. This further authorizationmay be done where merchants possess two or more identity cards, themerchant will be required to have a secondary authorization forprocessing of credits in excess of a value set up on merchantregistration or where matching does not occur. This uniquely providessecurity against fraudulent processing of credits by individual membersof merchant staff colluding with third party consumers (who may bethemselves). Parameters such as specific value and velocity and volumeof credit transactions are specified in the merchant's operatingparameters upon registration or account maintenance and will bemonitored against both merchant and consumer accounts, and the audittrail and anti-fraud logs updated, providing a unique monitoring checkagainst multiple merchant-consumer combinations 422.

Where a merchant has two or more identity cards, the merchant may electduring registration or account maintenance to have a secondaryauthorization for processing of credits where a predefined credit limitis breached (for single or multiple transactions across specific andgeneral time periods). Where a particular merchant and/or consumer hasbreached its operating parameters across particular timescales of credittransactions, the user service agreement terms may restrict furtherprocessing of credits. Where a credit transaction breaches the operatingparameters, the transaction is halted, the merchant and consumeraccounts are updated, and relevant audit trail logs are updated 424. Aservice review is then instigated to investigate matters further.

Where a credit transaction is matched, or is further authorized and doesnot breach any operating parameters, the credit processing proceeds 426.Merchant settlement proceeds may be withheld to set-off/cover credittransactions for a specified period thereby providing protection againstincreasing, undetected fraud by otherwise authorized members of merchantstaff. Once processed, the consumer and merchant transaction accountsare updated accordingly 428 and a notification sent to the consumer bythe notification process. Funds are settled back to the consumer fromthe merchant account in accordance with the user service agreement.Consumer and merchant accounts will be updated, and credit transactionand audit log files updated 430. The status of the credit transaction isset to “completed.” The credit transaction log is monitored forvelocity, volume and value checks against merchant and consumeraccounts, to facilitate anti-fraud checks.

As noted previously the present invention can be used for many differenttransaction types. The same basic principles apply to all of these.However, as will be appreciated, the specifics will vary. For example,for face-to-face transactions where the consumer will take the goodsaway with them, once both parties are authenticated, the transaction canbe concluded as normal, although without the consumer's financialdetails being made available to the merchant. Hence, for face-to-facetransactions there is generally no need to check whether the goods havebeen dispatched etc. In contrast, these considerations are clearlyimportant for all orders for which the consumer will be unable to accessor take goods physically away at the time of transaction, for examplefor Internet or telephone or mail order transactions. In this case, theconsumer's identity code and address code are needed to help identifywhere goods are to be sent when dispatched. Only where prior orderlodgement and merchant validation has been recorded will details of theorder be stored within the consumer's and/or merchant's user accounts onthe transaction system 1.

A skilled person will appreciate that variations of the disclosedarrangements are possible without departing from the invention. Forexample, although the transaction server, authentication server, paymentserver and any server required by the communications system are shown asphysically separate, or one or more of the transaction system 1 serverfunctions may be incorporated within the same physical server. Inaddition, whilst the description refers generally to the use of servers,it will be appreciated that any computer processor or computer basedsystem could be used. Accordingly the above description of the specificembodiment is made by way of example only and not for the purposes oflimitation. It is clear that minor modifications may be made withoutsignificant changes to the operation described.

1. A computer-implemented method for facilitating electronictransactions between a first party and one or more second parties,comprising: establishing a first relationship with the first party, thefirst relationship defining a dynamically controllable and selectableselection of at least one user-specified and user-specificauthentication method selected from a plurality of stored authenticationmethods of different types operating on an authentication device over aplurality of different communication channels and useable toauthenticate the identity of the first party in a non-predictable andanonymous manner; establishing a second relationship with at least oneof said one or more second parties; storing one or more associationsbetween payment methods and transactions, the one or more associationsspecified by the first party; and upon receiving an authenticationrequest related to a transaction with one or more of the second parties:controlling the authentication device to validate the identity of thefirst party by presenting the first party with at least one of thepreviously selected user-specified and user-specific storedauthentication methods on the authentication device; and upon successfulauthentication using the at least one of the previously selecteduser-specified and user-specific stored authentication methods on theauthentication device, initiating the transaction with said one or moresecond parties using one or more payment methods associated with thetransaction.
 2. The computer-implemented method of claim 1, wherein theassociations associate payment methods with types of transactions. 3.The computer-implemented method of claim 2, wherein the associationsassociate payment methods with a particular second party.
 4. Thecomputer-implemented method of claim 1, further comprising: uponreceiving an authentication request related to the transaction and priorto the initiating step, validating the transaction against one or moreparameters.
 5. The computer-implemented method of claim 4, wherein theone or more parameters include one or more selected from the groupconsisting of: payment type, payment value, transaction frequency,transaction velocity, bulk spend within a period, credit risk, and fraudrisk.
 6. The computer-implemented method of claim 1, wherein saidtransaction comprises a purchase of goods or services.
 7. Thecomputer-implemented method of claim 1, wherein said transactioncomprises a disbursement of cash from a cash disbursement mechanism. 8.The computer-implemented method of claim 1, wherein said transactioncomprises a money transfer.
 9. The computer-implemented method of claim1, wherein the transaction includes executing a first financing methodfor the transaction.
 10. The computer-implemented method of claim 1,wherein the entire transaction is completed without identifying anyfinancial information of the consumer to the first of said one or moresecond parties.
 11. The computer-implemented method of claim 1, whereinthe plurality of stored authentication methods of different typesinclude interactive voice recognition via a voice telecommunicationschannel.
 12. The computer-implemented method of claim 11, wherein theinteractive voice recognition is directed to a predeterminedtelecommunications device.
 13. The computer-implemented method of claim1, wherein the plurality of stored authentication methods of differenttypes include a fingerprint-based authentication method implemented on adevice including both a fingerprint reader and a mobiletelecommunications apparatus.
 14. The computer-implemented method ofclaim 1, wherein the plurality of stored authentication methods ofdifferent types include providing an answerback PIN via an SMS message.15. The computer-implemented method of claim 1, wherein the plurality ofstored authentication methods are not associated with the transaction.16. The computer-implemented method of claim 1, wherein the plurality ofstored authentication methods are not prescribed by the second partyinvolved in the transaction.
 17. The computer-implemented method ofclaim 1, wherein information about the first party is not transmitteduntil the second party is ready to transfer possession of a subject ofthe transaction to the first party.
 18. The computer-implemented methodof claim 17, wherein the information about the first party includes aship-to address.
 19. The computer-implemented method of claim 1, whereinthe plurality of stored authentication methods of different typesoperate on different communication channels from the transaction. 20.The computer-implemented method of claim 1, wherein at least one of theplurality of stored authentication methods utilize one or more selectedfrom the group consisting of: IP protocol data and device identity data.